tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Tomcat 6.0.35 -crossing maxThreads configured count
Date Mon, 23 Jan 2012 16:25:27 GMT
gnath wrote:
> Please ignore my previously sent edited configuration. Here is what our configurations
are without editing them :
> <Executor name="tomcatThreadPool"
>                   namePrefix="catalina-exec-"
>                   maxThreads="500"
>                   minSpareThreads="50"/>
>     <Connector enableLookups="false" executor="tomcatThreadPool"  port="40080"
>  protocol="HTTP/1.1"
>                connectionTimeout="20000"
>                redirectPort="40443" address=""/>
>     <Connector enableLookups="false" executor="tomcatThreadPool"  port="40443" protocol="HTTP/1.1"
>                scheme="https" secure="true"
>                clientAuth="false" sslProtocol="TLS" address=""
>                keystoreFile="/usr/bin/keystore" keystorePass="password" />
> Please let me know. I appreciate your help in looking into this
I have not gone back to your first message, but from the subject I guess that your concern

is that you think that there are a lot of threads active in Tomcat, as compared to the 
number of HTTP requests that your server is receiving.
The following does not in any way mean that you should not follow the other advices, and 
verify your assumptions, using the appropriate tools.
But you may also want to have a look at the Connector's keep-alive setting.


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).


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.

In your configuration, you do not use an explicit keepAliveTimeout attribute, so it 
defaults to the connectionTimeout, which is 20 seconds.

Imagine that your server receives requests for pages, at the rate of 10 per second.
And that each page contains 3 embedded thumbnail images.  So after the first request for 
the page, the browser is going to issue 3 more requests for the embedded images.
By default, the keep-alive is active, which means that this all happens over the same HTTP

(or HTTPS) connection; and since it all happens over the same established connection, it 
will also be processed by the same Tomcat thread. Which is all basically all A Good Thing,

because it avoids having to tear down and rebuild connections and threads for each request.

Processing the 4 consecutive requests of the browser is likely to take only a fraction of

a second altogether.
After these 4 requests are served, the keepAliveTimeout starts running, and with your 
current settings it does so for 20 seconds.  During these 20 seconds, the thread which has

processed the 4 requests keeps waiting, in case the browser has any more requests to send

over the same connection (which it probably has not, because the user is considering his 
next move).
1/10th of a second after the first request, another browser also sends a request. Since 
the first thread is still busy, a new one is allocated.  After a fraction of a second, 
that one goes in keepAliveTimeout. And so on.
So all in all, this scenario is allocating new threads at the rythm of 10 per second; and

it is only after the first 20 seconds have gone by, that the timeout of the first thread 
expires, that it can close its connection, and return to the pool to process another 
browser request. By that time, according to the above scenario, you have about 200 threads

waiting in their keep-alive status, and basically not doing anything.

I am not saying that your scenario matches the above, and only you can determine that.
But it could explain a high number of threads apparently idle.
So if those idle threads bother you, it may be worth trying an explicit lower 
keepAliveTimeout (e.g. 5 s), and monitor the impact.

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

View raw message