tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard W. Smith, Jr." <smithh032...@gmail.com>
Subject Re: Avoiding/Handling SocketTimeoutException(s) when web application serving resources to mobile clients
Date Mon, 11 Nov 2013 14:07:30 GMT
On Mon, Nov 11, 2013 at 5:41 AM, André Warnier <aw@ice-sa.com> wrote:

> Howard W. Smith, Jr. wrote:
>
>> On Sun, Nov 10, 2013 at 9:14 AM, Howard W. Smith, Jr. <
>> smithh032772@gmail.com> wrote:
>>
>>  Caused by: java.net.SocketTimeoutException
>>> at
>>> org.apache.tomcat.util.net.NioBlockingSelector.write(
>>> NioBlockingSelector.java:127)
>>> at
>>> org.apache.tomcat.util.net.NioSelectorPool.write(
>>> NioSelectorPool.java:174)
>>>  at
>>> org.apache.coyote.http11.InternalNioOutputBuffer.writeToSocket(
>>> InternalNioOutputBuffer.java:163)
>>>
>>>
>> my apologies, based on this exception (above), I decided to provide you
>> with the following from my tomee/conf/server.xml:
>>
>>
>>     <Connector port="8080"
>> protocol="org.apache.coyote.http11.Http11NioProtocol"
>>                maxThreads="150" connectionTimeout="20000"
>> acceptorThreadCount="2"
>>                redirectPort="8443" socket.directBuffer="false"/>
>>
>>
>> I guess the answer may be the connectionTimeout="..." (above), but still
>> would like to know recommendations of others based on experience with web
>> application serving mobile clients. thanks.
>>
>>
> AFAIK, the "connectionTimeout" above applies specifically to this :
> - the client opens a TCP connection to the server
> - but then the client does not send any request over that connection
> (so the server waits and waits, until that timeout strikes).
> This is a classic way of doing a DoS attack : many clients connect and
> don't send a request (or do it very slowly), tying up server resources
> until the server is overwhelmed.
> In some Connector configurations, this does not necessarily tie up a
> Thread (only a TCP socket), but it does have the potential to tie up
> limited resources.
> The value of 20000 above is in milliseconds, so after a connection is
> established, the server will wait up to 20 seconds for a request to be
> received.
> I would not expect nowadays that any client, on any type of connection,
> would take that long to send a request on an established connection.  So I
> would certainly not make it larger, and you can probably reduce it
> significantly, and save resources.
>
>
>
Great, thank you!

I left it as-is and given the situation (which I communicated earlier), I
saw no need to increase the connectionTimeout value. Noted your
recommendation about decreasing the value...for now.

thanks again!

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