tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: AW: Too many connections in keepalive state in jk threadpool
Date Fri, 02 Mar 2012 17:53:28 GMT

The recommended way of replying to messages on this list, is to write your replies below 
the comment/question to which it relates.
It makes it much easier to follow the flow of the conversation.

> -----Ursprüngliche Nachricht-----
> Von: André Warnier [] 
> Gesendet: Freitag, 2. März 2012 13:01
> An: Tomcat Users List
> Betreff: Re: Too many connections in keepalive state in jk threadpool
> Beier Michael wrote:
>> Hi all,
>> we're running tomcat 7.0.23 on sun jdk 1.6.0_29, connected via ajp to httpd 2.2.21
using mod_jk 1.2.32.
>> I observed the behavior, that tomcat keeps threads in its ajp pool in keepalive state,
regardless of which timeouts (connectionTimeout and keepAliveTimeout) are configured in tomcat.
>> I tested three connector configurations and with all I see connections in tomcat
server status where the "Time" value amounts up to several million milliseconds, which is
more than configured in connectionTimeout/keepAliveTimeout.
>> This results in having 60-80 percent of the thread pool being in state "keepAlive".
>> 1)
>>     <Connector port="8309" protocol="AJP/1.3"
>>                maxThreads="200" redirectPort="8343" tomcatAuthentication="false"
>>                keepAliveTimeout="300000" connectionTimeout="300000" />
>> 2)
>>     <Connector port="8309" protocol="AJP/1.3"
>>                maxThreads="200" redirectPort="8343" tomcatAuthentication="false"
>>                keepAliveTimeout="300000" />
>> 3)
>>     <Connector port="8309" protocol="AJP/1.3"
>>                maxThreads="200" redirectPort="8343" 
>> tomcatAuthentication="false" />
>> In mod_jk the connection_pool_timeout is set to the same value as connectionTimeout
(only in seconds, not milliseconds).
>> I verified that the values are set correctly querying the parameters via JMX.
>> How can I avoid having so many threads in keepalive state - I don't have any idea
at the moment and can't see that there is an error in my configuration.
> Before discussing this, I find it useful to review the basics, such as in :
> and
> In other words, at the level of your front-end webserver (which I suppose you have, since
you are talking about mod_jk and AJP), do you really need a long KeepAliveTimeout ?
> (and similarly at the level of your Tomcat <Connector>'s above).
> As per the documentation :
> connectionTimeout	
> The number of milliseconds this Connector will wait, after accepting a connection, for
the request URI line to be presented. The default value is 60000 (i.e. 60 seconds).
> keepAliveTimeout	
> The number of milliseconds this Connector will wait for another AJP request before closing
the connection. The default value is to use the value that has been set for the connectionTimeout
> In other words,
> - connectionTimeout defaults to 60 seconds
> - if you do not specify either one of them, then they both default to 60 seconds.
> - if you do specify connectionTimeout and not KeepAliveTimeout, then KeepAliveTimeout
defaults to the same value as connectionTimeout.
> - your value above for KeepAliveTimeout (300000) means 5 minutes
> Do you really want one Tomcat thread to wait for 5 minutes doing nothing, just in case
the browser would decide to send another request on the same connection ?
> And do you really want, when a browser creates its initial TCP connection to your webserver,
to give it 60 seconds (or 5 mintes !) before it even starts sending its HTTP request on that
connection ?
Beier Michael wrote:
 > Hi,
 > all the points you've mentioned are important and have been considered. 5 minutes
 > timeout for connection / keepAlive is a very long time, but this is OK for our web apps
 > running in our intranet.

It may be ok for you, but it may also be the reason why you have processes/threads which 
remain alive and are blocking connections.

I do not know the deep details of how mod_jk works, but :
- the browser make a connection to the front-end server
- Apache httpd accepts the connection and passes it to a httpd child process, for request

- the browser sends a HTTP request over that connection, requesting Keep-Alive
- the front-end server's child processes the request.  In the process of doing this, 
mod_jk establishes a connection to the back-end Tomcat, and passes the request to Tomcat 
over that connection
- in Tomcat, a thread starts to process the request
- in Tomcat, the thread sends the response and finishes to process that request
- but because the connection is Keep-Alive, it does not close the connection (from 
mod_jk), and keeps waiting for more requests
- in the meantime, the Apache child who processed the request (sending it through mod_jk 
to Tomcat) will not close its connection to the browser either, and will probably keep its

connection to Tomcat open also
- in the meantime, another browser connects to the server, which will also result in an 
Apache front-end child waiting for 5 minutes doing nothing, and blocking a connection to 
Tomcat and a thread in Tomcat..
And so on.

It is probably more complex than that, since mod_jk will use a pool of connections to 
Tomcat, and try to keep them alive and re-use them, for efficiency reasons.
So it is a bit complicated to determine which KeepAlive "wins" here, and what in the end 
is causing these Tomcat threads to remain when they shouldn't.

 > But at the moment I'd be quite happy, if tomcat would make use of the defined timeouts

and terminate the threads, that have been in keepalive state for more than 5 minutes.
 > But this does not happen!
 > So my first goal is, to make tomcat respect the timeouts I define.
 > The second goal then might be fine tuning the timeouts.

My point was : first set your timeouts to a reasonable value (2-3 seconds for example), 
and then check if you still have a bunch of threads in Tomcat doing nothing.
If you still do, then you may have a problem worth investigating further.
But if you don't, then why make your life complicated and look for problems where there 
aren't any ?

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

View raw message