Roedy said:I have noticed a program that has worked for a long time now just
freezes as if it had a infinite timeout on HTTP GETs. This started
happening with JDK 1,6.0_18. Has anyone else noticed this?
Lothar Kimmeringer said:Until 1.5. AFAIR there was no setting in HttpUrlConnection
allowing you to reduce the timeout to something lower than
infinity, forcing you to do some workarounds to get a timeout
when connecting or working with Sockets created with
HttpUrlConnection (I assume you are talking about HttpUrlConnection).
I often find the standard HttpUrlConnection lacking, and usually go withLothar said:Until 1.5. AFAIR there was no setting in HttpUrlConnection
allowing you to reduce the timeout to something lower than
infinity, forcing you to do some workarounds to get a timeout
when connecting or working with Sockets created with
HttpUrlConnection (I assume you are talking about HttpUrlConnection).
Assuming specific timeout-settings is always a bad idea, so you
should set a timeout for yourself instead of hoping that the
default behavior of a VM keeps the same all time.
Regards, Lothar
Daniel said:I often find the standard HttpUrlConnection lacking, and usually go with
apache commons HttpClient instead. You have more control of the
process, if you care, but it also "works" out-of-the-box if you don't
want to configure it as much.
Last time I checked, they both implement HttpMethod and are derived fromLothar said:The last time I checked, GetMethod and PostMethod were two
classes sharing a lot of methods but not a common superclass.
So you end up with code like this
if (performGet) {
methodGet = new GetMethod(host + url);
methodGet.setQueryString(query);
methodGet.setDoAuthentication(authNeeded);
methodGet.getParams().setParameter("http.socket.timeout",
Integer.valueOf(timeout));
methodGet.getParams().setParameter(
HttpMethodParams.RETRY_HANDLER, retryhandler);
methodGet.setRequestHeader("Connection", "keep-alive");
methodGet.setRequestHeader("Cache-Control", "no-cache");
}
else {
methodPost = new PostMethod(host + url);
methodPost.setRequestHeader("Connection", "keep-alive");
methodPost.setDoAuthentication(authNeeded);
methodPost.getParams().setParameter("http.socket.timeout",
Integer.valueOf(timeout));
methodPost.getParams().setParameter(
HttpMethodParams.RETRY_HANDLER, retryhandler);
methodPost.setRequestHeader("Cache-Control", "no-cache");
}
if (methodGet != null){
statuscode = client.executeMethod(methodGet);
}
else{
statuscode = client.executeMethod(methodPost);
}
and so on. If you have a specific HTTP-session to handle
programmatically, HttpClient is nice, but if you have to
build different HTTP-requests in dependence of external
configurations, you have a lot of duplicate code that
is prone to errors.
Regards, Lothar
Daniel said:Last time I checked, they both implement HttpMethod and are derived from
HttpMethodBase. Perhaps you had a really old version, or misinterpreted
something else.
Our codebase has been using HttpClient 3.1, so that is why theLew said:I'm not seeing either one, nor 'HttpMethodBase', nor 'HttpMethod' in
the HttpClient Javadocs. I find 'HttpGet' and 'HttpPost', which
inherit from 'HttpRequestBase' and implement 'HttpMessage', and seem
roughly equivalent to what you're talking about.
<http://hc.apache.org/httpcomponents-client/httpclient/apidocs/
index.html>
From <http://hc.apache.org/>:
"HttpComponents Client is a successor of and replacement for Commons
HttpClient 3.x. Users of Commons HttpClient are strongly encouraged to
upgrade. ...
"Commons HttpClient 3.x codeline is nearing the end of life. All users
of Commons HttpClient 3.x are strongly encouraged to upgrade to
HttpClient 4.0."
The last time I checked, GetMethod and PostMethod were two
classes sharing a lot of methods but not a common superclass.
So you end up with code like this
if (performGet) {
methodGet = new GetMethod(host + url);
methodGet.setQueryString(query);
methodGet.setDoAuthentication(authNeeded);
methodGet.getParams().setParameter("http.socket.timeout",
Integer.valueOf(timeout));
methodGet.getParams().setParameter(
HttpMethodParams.RETRY_HANDLER, retryhandler);
methodGet.setRequestHeader("Connection", "keep-alive");
methodGet.setRequestHeader("Cache-Control", "no-cache");
}
else {
methodPost = new PostMethod(host + url);
methodPost.setRequestHeader("Connection", "keep-alive");
methodPost.setDoAuthentication(authNeeded);
methodPost.getParams().setParameter("http.socket.timeout",
Integer.valueOf(timeout));
methodPost.getParams().setParameter(
HttpMethodParams.RETRY_HANDLER, retryhandler);
methodPost.setRequestHeader("Cache-Control", "no-cache");
}
and so on. If you have a specific HTTP-session to handle
programmatically, HttpClient is nice, but if you have to
build different HTTP-requests in dependence of external
configurations, you have a lot of duplicate code that
is prone to errors.
I'm not seeing either one, nor 'HttpMethodBase', nor 'HttpMethod' in
the HttpClient Javadocs. I find 'HttpGet' and 'HttpPost', which
inherit from 'HttpRequestBase' and implement 'HttpMessage', and seem
roughly equivalent to what you're talking about.
<http://hc.apache.org/httpcomponents-client/httpclient/apidocs/
index.html>
From<http://hc.apache.org/>:
"HttpComponents Client is a successor of and replacement for Commons
HttpClient 3.x. Users of Commons HttpClient are strongly encouraged to
upgrade. ...
"Commons HttpClient 3.x codeline is nearing the end of life. All users
of Commons HttpClient 3.x are strongly encouraged to upgrade to
HttpClient 4.0."
You know what you get when you assume. The OP provided a dearth of
information about exactly what he's doing. Perhaps he might consider
sharing the details, or even providing an SSCCE.
The last time I checked, GetMethod and PostMethod were two
classes sharing a lot of methods but not a common superclass.
So you end up with code like this
The code is posted at http://mindprod.com/products1.html#VERCHECK
When I get a round tuit, I will prune this back to a SSCCE.
I was hoping someone else was having the problem and had solved it or
had read a post somewhere about timeouts not behaving the way they use
to.
Oddly, when I run the program a second time, usually it completes the
read immediately and successfully.
Are you complaining about Sun or Apache?
Given that the code was explicit stated to be Apache, then
complaining to SUN would not make much sense.
Sounds more like a very slow DNS server and your immediate DNS server
having the name cached the second time.
Roedy said:He was not explicit. If you know that GetMethod and PostMethod are
unique to Apache, you could infer that. But Lothar did not state it
explicitly. The audience is wider than those who post. It always
helps to make things abundantly clear.
Roedy said:He was not explicit. If you know that GetMethod and PostMethod are
unique to Apache, you could infer that.
But Lothar did not state it
explicitly. The audience is wider than those who post. It always
helps to make things abundantly clear.
Arne said:Sure?
HttpClient 2.0.2 has a common super class.
Lothar said:As I said: "The last time I checked" It's been quite a while now,
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.