On Mon, Nov 11, 2013 at 11:22 AM, Howard W. Smith, Jr. < smithh032...@gmail.com> wrote:
> On Sun, Nov 10, 2013 at 5:08 PM, Igor Cicimov <icici...@gmail.com> wrote: > > > For Sun Java for example you can try the following: > > > > -Dsun.net.client.defaultReadTimeout=1800000 > > > > which will increase the socket timeout to 30 minutes lets say if the > > default one is not enough in case or slow client. Another thing to check > is > > your OS socket timeout setting, on linux systems for example: > > > > net.ipv4.tcp_keepalive_time = 300 > > > > and try adjusting it according to your needs. > > > > Would love to hear some other people experiences and thoughts regarding > > this as well, this is really annoying one to troubleshoot. > > > > I like the following that was mentioned in a stackoverflow answer[1]: > > > It just means the client isn't sending. You don't need to worry about it. > Browser clients come and go in all sorts of strange ways. > > Correct, and IE is worst with their tradition of not complying to the standards. Especially if your app is using AJAX http POST requests in shoert succession and gets worse in case if this id done over SSL. There is heaps of articles and questions in various forums like this one for example: http://stackoverflow.com/questions/4796305/why-does-internet-explorer-not-send-http-post-body-on-ajax-call-after-failure which talks about timeout in case of re-posting POST requests in case of failure (IE 6,7,8 send only the header with payload missing so the server timeouts). The remedy is disabling the keep-alive on the server side but this comes with the expense of every AJAX call opening new connection. > I wouldn't put the server read timeout too high: it ties up a thread. If > a client opens a connection to the server and doesn't send anything > immediately it is misbehaving pretty badly. > > I agree with all of that and based on that, I will not modify the NIO > connectiontimeout value. I would like to prevent the stacktrace from being > logged in tomcat7-stderr log file, so I think I will catch the exception in > my servlet filter. > > I agree with this one too, no matter how high or low you set your timeout it will eventually strike since the client simply is not sanding the complete http request in some particular cases. Also you didn't say anything about any load balancer or proxy fronting your application. It is worth checking the timeouts there as well and align them with the connection timeout on your server (in case you do use one of course). > > [1] http://stackoverflow.com/a/17079991/933054 >
