Hello Andre, et al, On Wed, Feb 6, 2013 at 2:40 PM, André Warnier <a...@ice-sa.com> wrote:
> Leon Rosenberg wrote: > ... > > > >> We have 105 threads in this state over multiple hours. >> >> Question: Could it be that we have connection leakage through keep-alive >> connections? Is there are possibility to reduce them? >> I understand that jboss have the same apache 11 connector, however all >> extended configuration options are removed from the doc: >> http://docs.jboss.org/**jbossweb/7.0.x/config/http.**html<http://docs.jboss.org/jbossweb/7.0.x/config/http.html> >> >> > I don't know Jboss at all, but assuming that it is Tomcat behind, and > assuming that they have not replaced the HTTP Connector by their own, then > their documentation is wrong, and you could try the following attributes : > > keepAliveTimeout > > The number of milliseconds this Connector will wait for another HTTP > request before closing the connection. The default value is to use the > value that has been set for the connectionTimeout attribute. Use a value of > -1 to indicate no (i.e. infinite) timeout. > > connectionTimeout > > The number of milliseconds this Connector will wait, after accepting a > connection, for the request URI line to be presented. Use a value of -1 to > indicate no (i.e. infinite) timeout. The default value is 60000 (i.e. 60 > seconds) but note that the standard server.xml that ships with Tomcat sets > this to 20000 (i.e. 20 seconds). > > connectionTimeout can play a role if there are (nefarious) clients which > establish a connection to your server, but then just hang there and never > send any request on that connection. That's one known form of DOS attack. > > A keepAliveTimeout of 60 seconds seems quite high to me. It means that > - the browser created a connection and asked for it to be "persistent" > - the browser sent a request on this connection > - the server allocated one thread to process that request > - the thread sent the response to that request > - now the thread, instead of being immediately released to the pool of > idle threads (to process some other request) hangs on to the connection, > waiting to see if the browser has another request to send on it. And it > hangs so for keepAliveTimeout time (60 seconds here in the default case). > - if another request comes within a short period of time, the benefit is > that the connection has not been closed, so the browser and server do not > have the overhead of establishing a new one (a few packets exchanged, a few > thousand lines of code ran). > But if the browser has no more requests to send right now, you are wasting > an open TCP connection and a thread sitting there just waiting. > I can see this as useful nowadays if your application serves a lot of > pages containing many embedded <img> tags or the like, since the browser > will not have to open a new connection for each image that it wants to > retrieve. > But even then, a few seconds of keepAlive would suffice. > > My analysis is pretty near yours. Still I don't think we are DOSed somehow, but some 3K concurrent sessions could indeed block few hundred of threads by simply keeping their browsers open and doing nothing. I will try to reduce keep alive settings just to be sure :-) I hope Jboss submits the parameter one on one ;-) regards Leon
