Rainer Jung wrote:
On 14.03.2013 10:04, David Kumar wrote:
Hey,
thanks for note..
Attached you can find a new list.
So, java is keeping these connections in close_wait.
close_wait for an AJP connection seen from Tomcat means the other side -
mod_jk - has closed the connection, but not Tomcat.
This is often due to a shorter Timeout on the mod_jk side than on the
Tomcat side. It is not a problem per se, but it is if it happens for too
many connections for a too long time.
I vaguely remember that you have a 10 second socket_timeout in your
workers.properties. That's typically bad. Look at the example config in
the source mod_jk download.
It could be, that your requests in Tomcat got stuck and Tomcat still is
in the state of working on the requests, therefore keeping the
connection open to send back stuff finally, whereas mod_jk has already
timed out. To check for that, take a couöple of threa dumps (not: heap
dumps) of the running Tomcat process while the close_wait problem is
visible. Check what your Tomcat threads are currently doing, e.g. are
they mostly sitting idle in the thread pool or executor, or are many of
them deep in your application stacks and waiting for database, locks or
other stuff.
Hi Rainer, a question to you :
In a previous post, David posted the output of "netstat -t -pan".
In that output, there are about 1900 connections from Apache to Tomcat's AJP connectors,
in state "TIME_WAIT".
As far as I know, this indicates that the connection is closed from the point of view of
Apache, and this TIME_WAIT should last only a few sec. maximum, and then should go away.
Why does he have so many though ? I can't see anything like that on any of my
servers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
