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 Mon, 05 Mar 2012 13:06:46 GMT
Hallo Herr Jung,

>-----Ursprüngliche Nachricht-----
>Von: Rainer Jung [mailto:rainer.jung@kippdata.de] 
>
>Hallo Herr Beier,
>
>On 02.03.2012 11:19, 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.
>
>Educated guess: you have an interval based cping/cpong 
>connection check 
>configured for mod_jk.

You're right, that's the way cping/cpong was configured.

>Any cping will wake up the thread waiting for data on the 
>connection and 
>will reset the timeouts. But a cping will be ommediately answered by a 
>cpong and not update the "last request" time. So that would 
>explain, why 
>your connections never timeout though the Manager shows constantly 
>increasing times for the last request seen.

OK, that's an important information on the value of "Time" in tomcat
server status. Maybe it should be added to jk worker docs and/or
tomcat manager-howto.

>Usually that feature would be activated for mo_jk using the 
>JkWatchdogInterval in combination with ping_mode "I" or "A". 
>In case you 
>are unsure about the effects of the various jk configuration options, 
>you might post them here (remove sensitive data before posting).
>
>I'd say the current behaviour is a bit problematic, but I don't see an 
>easy improvement. So if your focus is on keeping the number of idle 
>connections low you would need to switch off interval cpings. Cping 
>before rquests and after opening connections are fine (improves 
>stability and reduces the likeliness of race conditions).

I disabled interval cping by setting "ping_mode = C,P" instead of "A".
At the moment everything looks good and tomcat behaves as expected.

Thank's for your help!

Best regards,
Michael Beier

Team SIS OIOAW (Web Basis)
 
EnBW Systeme Infrastruktur Support GmbH
Durlacher Allee 93
76131 Karlsruhe

Tel.: +49 (7 21) 63 - 14545 
Fax: +49 (7 21) 63 - 15099
mailto:m.beier@enbw.com

EnBW Systeme Infrastruktur Support GmbH
Sitz der Gesellschaft: Karlsruhe
Handelsregister: Amtsgericht Mannheim ­ HRB 108550
Vorsitzender des Aufsichtsrats: Dr. Bernhard Beck
Geschäftsführer: Jochen Adenau, Hans-Günther Meier

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


Mime
View raw message