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 13:40:12 GMT
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 :


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.


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.

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

View raw message