Hello all,

I'm sorry to bother again but I was wondering whether any of you has some feedback about the following problem.

Synopsis: Tomcat hangs because the threadpool is empty, but traffic is really low ==> what can cause all these threads/connections to hang?

The Whole story.
I have a web service published together with a webapp under Tomcat 4.1.24-LE on linux redhat. The web service is built using Axis 1.0
facilities and it interacts with an Oracle db.
Up to date it has worked like a charm: more than 6 months up & running without any needs of a restart.


A few days ago the server entered in a not responding state. Examining the log I have discovered that:

****************CUT HERE****************
Oct 13, 2004 4:02:04 PM org.apache.tomcat.util.threads.ThreadPool logFull
SEVERE: All threads are busy, waiting. Please increase maxThreads or check the servlet status150 150
****************CUT HERE****************



HTTP connections are handled through non-SSL Coyote HTTP/1.1 Connector on port 8080. This is the rilevant portion of server.xml


****************CUT HERE****************
   <Connector className="org.apache.coyote.tomcat4.CoyoteConnector"
              port="8080" minProcessors="100" maxProcessors="150"
              enableLookups="true" redirectPort="8443"
              acceptCount="10" debug="0" connectionTimeout="20000"
              useURIValidationHack="false" disableUploadTimeout="true" />
****************CUT HERE****************


Dumping the network connections I have found (not surprisingly): *) 89 connections in SYN_RECV state *) 133 connections in CLOSE_WAIT state

Examining the access log I have found nothing in particular, last access was at 13/Oct/2004:15:44:09, a GET on one of the webapp's servlets, served successfully.

Examining the application log I only see a few exceptions caused by an RDBMS shutdown. I am asking myself if this can be the cause of zombie threads, but it seems strange to me.

Nothing seems to be happened at 4:02:04 PM, or at least the JVM was not able to log any information right before the block (it seems reasonable because the server was not able to instantiate any thread from the pool in order to manage the request; the question is whether access log writes before getting a thread from the pool or after that).

Do you have any ideas? I may increase ThreadPool dimension, but when the block occurred traffic was low and it doesn't seem to justify any change on the configuration side. Is it a Tomcat issue? We are planning to upgrade to 4.1.30 very soon, but could it be worth to go towards 4.1.31 or 5.x.y (not really planned yet)?

I'd appreciate any feedback about it.

TIA
Giuliano



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to