Skip to main content

default timeout for URLConnection changed in jre 1.7?

6 replies [Last post]
rgollila
Offline
Joined: 2010-10-18

I am observing intermittent java.net.SocketTimeoutException exception reading files only with jre 1.7. Its my understanding that the default timeout for a URLConnection (set via setConnectTimeout()) is infinite. With 1.7 it appears it is no longer infinite by default. We have never set a timeout explicitly so I am wondering if the default has changed to a finite value? I am using build 107 or jre 1.7.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
rgollila
Offline
Joined: 2010-10-18

It appears this problem has something to do with http keep-alives. When I disable keep-alives on the IIS web server the problem goes away. Any significant changes in the area with jre 1.7?

chegar
Offline
Joined: 2008-07-10

I filed CR 6993490: "SocketTimeoutException on HTTP keep-alive connections" against this issue.

There are three places in the HTTP client implementation where the read timeout is set for a potentially blocking internal operation, error stream buffering, Expect 100-Continue handling, and keepalive cleaner. The read timeout is then not correctly reset (when using the default read timeout). I suspect your code must be hitting one of these. One workaround is to set a large read timeout using URLConnection.setReadTimeout(int).

For the keepalive cleaner ( read off unread response body, if possible, then cache the connection for reuse ) the read timeout is set to 5 seconds, and is not properly reset. Same for Expect 100-Continue support (if you use the "Expect: 100-Continue" in your request header). Error stream buffering, enabled through the sun.net.http.errorstream.enableBuffering system property sets a read timeout of 60 millis ( buffers responds body for responses with an response code of >= 400).

Surprisingly this was never noticed before. Only Expect 100-Continue handling is new in JDK7, but this is a timing issue and it may be that the timing has just changed in JDK7. It would be interesting to identify which of these three ( if any ) is causing your problem.

rgollila
Offline
Joined: 2010-10-18

Great! Thanks for entering that CR! Unfortunately, the suggested workaround of setting a large read timeout using URLConnection.setReadTimeout(int) won't work for our application. We have to support JRE's back to 1.3.1 and that method is only available starting with jre 1.5. I tried accomodating the lack of support in earlier jre's by calling the setReadTimeout using reflection only in newer jre's, but that triggers a security exception. Apparently reflection is not supported for that method. At any rate, I noted the state of CR 6993490 is '8-Fix Available'. Do you know what that means? Does this mean it will be fixed for the first release of 1.7?

rogerl
Offline
Joined: 2004-11-15

The '8-Fix Available' means that there is a fix but it has not yet been integrated in to the main source tree. You can expect the fix to be in the 'integrated' state at some point in the near future and then will be available to you in one of the weekly snapshots.

-Roger

alanb
Offline
Joined: 2005-08-08

I'm not aware of any changes in this area. Can you narrow this one down to a small test case to demonstrate the issue? It would be great if you could submit a bug with the test case so that the bug can be analyzed (it's really important to pick up regressions, if this is what this is).

sujikin
Offline
Joined: 2005-04-03

Plese check the javadoc for URLConnection in java 1.7

I don't think the default has changed at all.

Message was edited by: sujikin