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: AW: Too many connections in keepalive state in jk threadpool
Date Fri, 02 Mar 2012 20:43:32 GMT
>-----Ursprüngliche Nachricht-----
>Von: André Warnier [mailto:aw@ice-sa.com] 
>Gesendet: Freitag, 2. März 2012 18:53
>An: Tomcat Users List
>Betreff: Re: AW: Too many connections in keepalive state in jk 
>threadpool
>
>Hi.
>
>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 [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 ?
>> 
>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.

That's a very sophisticated thesis. I configured a 300 second
KeepAliveTimeout and find threads in keepalive state that are
more than 1000 seconds old. Why should this behaviour change,
if I reduce the configured timeout? But .. I'll try ..

>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 
>processing
>- 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 ?

As I wrote above - I'll try and get back to you.

Best regards,
Michael

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