tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Strange thread behavior in tomcat/jboss 7
Date Wed, 06 Feb 2013 15:29:22 GMT
Leon Rosenberg wrote:
> 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 ;-)

I am far from an expert in the matter, but JMX should allow you to view whatever 
parameters are in effect in the end. That's at the JVM level, so it should be independent

of JBoss.

Also, don't know if it is your case, but if you are using Windows Integrated 
Authentication, setting keepAlive very low may have detrimental effects, forcing WIA to 
re-authenticate the user sessions more frequently.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message