Where should I start investigating SocketTimeoutException: Read timed out

Question

Every now and then I see following stacktrace in the log in which, HttpClient socket times out trying to access text/script content from another se

Answer 1

One more aspect that has not been covered here is Firewall.

I have found that SocketTimeoutExceptions may often be related to a port not being open for communication or a firewall blocking communication from selected machines only.

In case you are debugging an issue make sure you also investigate if there is a firewall between the two machines trying to communicate and if there is one make sure the ports are available for communication between the two.

Interesting things about firewall related issues is that it does not let you know if the server is down or not responding. Typical behavior is to let the client wait forever. So you are always left in dark. A simple telnet on the server port should show if its available/open for communication.

Hope this helps.

Answer 2

Track 1

As per the javadocs Httpclient does not seem to have have a default value of the Socket timeout. To answer the question in your update - the session timeout will not be in effect here. Weblogic's default is 30 minutes for session timeout.

The server session timeout represents the amount of time the HttpSession will be retained in memory if the user has not accessed the server.

The socket timeout is the amount of time to keep the server socket open while data is being transferred back to the caller. This could even be the server is still processing and writing back data but it's taking rather long and the client has just timed out waiting for it.

Some links suggest this default is 60 seconds but the javadocs dont say anything, in any case you can set this value to something like 120 seconds to see if it helps

http://hc.apache.org/httpclient-3.x/apidocs/org/apache/commons/httpclient/params/HttpConnectionParams.html#setSoTimeout(int)

What you need is to time the timeouts - if that's clear. Meaning - Do these errors appear after 30 sec, 60 sec or 5 minutes of the outgoing request?

I would change the SO_Timeout and try again

Track 2 - OS parameters

There are the recommended BEA parameters for NDD values which govern how long incoming connections are kept open and how many are queued and so on. On Solaris these are got by running

/usr/sbin/ndd -get /dev/tcp tcp_time_wait_interval 
/usr/sbin/ndd -get /dev/tcp tcp_conn_req_max_q 
/usr/sbin/ndd -get /dev/tcp tcp_conn_req_max_q0 
/usr/sbin/ndd -get /dev/tcp tcp_ip_abort_interval 
/usr/sbin/ndd -get /dev/tcp tcp_keepalive_interval 

Can you check the Oracle docs for the equivalent commands on Linux, and what values they should be set at. On Solaris my experience is the defaults are not enough and they need to be upped to BEA (Oracle) recommendations

Track 3: Weblogic / External Access Logs

Have you enabled HTTP Access Logs on the server? Do these failed requests show up with any response byte size or do they show 0 response size? What error code or HTTP status code is returned?

Or perhaps these timed out ones are not recorded in the access logs at all?

Here, I'm assuming the external server on which time outs occur is also Weblogic, if not - this question is directed to the external server team for their equivalent platform.

** Others **

Usually thread dumps help, but the thread dumps should be taken on the server which is having a timeout problem. You are the client and you have successfully obtained a connection, after that it times out when reading the response. So is the external server overloaded ? Lack of threads? CPU high? Too many concurrent requests?

Answer 3

You should investigate

(a) the default or explicit HttpClient read timeout, whichever is in use;

(b) why the server isn't responding within that period, if it is supposed to (view the server logs),

(c) otherwise why the timeout is set too short. Many timeouts are set too short, e.g. a few seconds. They should be a decent fraction of a minute, and if the expected response time is longer, double or triple the expected response time.