Prev: Runtime Devirtualization
Next: Subversion in 2010 and Beyond
From: Roedy Green on 20 Jan 2010 09:00
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?
--
Roedy Green Canadian Mind Products
http://mindprod.com
Responsible Development is the style of development I aspire to now. It can be summarized by answering the question, �How would I develop if it were my money?� I�m amazed how many theoretical arguments evaporate when faced with this question.
~ Kent Beck (born: 1961 age: 49) , evangelist for extreme programming .
From: Lothar Kimmeringer on 20 Jan 2010 10:33
Roedy Green wrote:

> 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?

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
--
Lothar Kimmeringer E-Mail: spamfang(a)kimmeringer.de
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!
From: Lew on 20 Jan 2010 11:44
Roedy Green wrote:
>> 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 <news200...(a)kimmeringer.de> wrote:
> 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).
>

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.

> 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.
>

--
Lew
From: Daniel Pitts on 20 Jan 2010 12:22
Lothar Kimmeringer wrote:
> Roedy Green wrote:
>
>> 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?
>
> 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
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.

--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
From: Lothar Kimmeringer on 20 Jan 2010 14:53
Daniel Pitts wrote:

> 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.

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
--
Lothar Kimmeringer E-Mail: spamfang(a)kimmeringer.de
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!
 |  Next  |  Last
Pages: 1 2 3 4 5 6 7
Prev: Runtime Devirtualization
Next: Subversion in 2010 and Beyond