On 15.03.2013 11:47, André Warnier wrote: > 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.
TIME_WAIT is a state which means the connection is closed by both sides but the TCP stack still blocks the (server port, server ip, client port, client IP) quadruple for reuse to prevent long overdue packets of the old connection to disturb the new connection. It doesn't prevent new connections from being created nor are there still process resources on client or server being used for those connections (threds, buffers). It is just an entry in the OS TCP connection hash. The TIME_WAIT state is only used on the side of the connection that started the connection shutdown, i.e. that first send the FIN. The other side doesn't go into TIME_WAIT. If your clients typically start the connection shutdown you won't see the TIME_WAIT. Connections are kept in TIME_WAIT for seconds to about a minute depending on your OS and TCP tuning. For a service which uses a lot of new connections per second and initiates the shutdown for them itself it is not uncommon to see several hundreds to thousands of TIME_WAIT connections. If the count goes up into the range of 10.000-50.000 you could start running into inefficiencies of the TCP connection hash handling (depending on the OS). Regards, Rainer --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
