tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Beier Michael <M.Be...@EnBW.com>
Subject AW: Too many connections in keepalive state in jk threadpool
Date Fri, 02 Mar 2012 13:24:26 GMT
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.
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.

Best regards,
Michael

-----Ursprüngliche Nachricht-----
Von: André Warnier [mailto:aw@ice-sa.com] 
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 :

http://en.wikipedia.org/wiki/HTTP_persistent_connection
and
http://tomcat.apache.org/connectors-doc/generic_howto/timeouts.html

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

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 ?




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message