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:a...@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.
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 ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
