On Mon, Nov 11, 2013 at 5:41 AM, André Warnier <a...@ice-sa.com> wrote:
> Howard W. Smith, Jr. wrote: > >> On Sun, Nov 10, 2013 at 9:14 AM, Howard W. Smith, Jr. < >> smithh032...@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!
