tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leon Rosenberg <>
Subject Re: Strange thread behavior in tomcat/jboss 7
Date Wed, 06 Feb 2013 14:32:43 GMT
Hello Andre, et al,

On Wed, Feb 6, 2013 at 2:40 PM, André Warnier <> 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:
> 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 ;-)


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