tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Igor Cicimov <icici...@gmail.com>
Subject Re: Avoiding/Handling SocketTimeoutException(s) when web application serving resources to mobile clients
Date Mon, 11 Nov 2013 01:54:42 GMT
On Mon, Nov 11, 2013 at 11:22 AM, Howard W. Smith, Jr. <
smithh032772@gmail.com> wrote:

> On Sun, Nov 10, 2013 at 5:08 PM, Igor Cicimov <icicimov@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message