> > RUNNABLE and WAITING are thread states in the JVM. They don't relate in > > general to states inside Tomcat. In this special situation they do. > > > > The states you observe are both completely normal in themselves. One > > (the stack you abbreviate with RUNNABLE) is handling a persistant > > connection between web server and Tomcat which could send more requests, > > but at the moment no request is being processed, the other (you > > abbreviate with WAITING) is available to be associated with a new > > connection that might come in some time in the future. > > > > [Pantvaidya, Vishwajit] Thanks Rainer. The RUNNABLE thread - is it a > connection between Tomcat and webserver, or between Tomcat and AJP? Is it > still RUNNABLE and not WAITING because the servlet has not explicitly > closed the connection yet (something like > HttpServletResponse.getOutputStresm.close) > > > [Pantvaidya, Vishwajit] My problem is that tomcat is running out of > threads (maxthreadcount=200). My analysis of the issue is: > - threads count is exceeded because of a slow buildup of RUNNABLE threads > (and not because number of simultaneous http requests at some point > exceeded max thread count) > - most/all newly created TP-Processor threads are in RUNNABLE state and > remain RUNNABLE - never go back to WAITING state (waiting for thread pool) > - in such case, I find that tomcat spawns new threads when a new request > comes in > - this continues and finally tomcat runs out of threads > - Setting connectionTimeout in server.xml seems to have resolved the issue > - but I am wondering if that was just a workaround i.e. whether so many > threads remaining RUNNABLE indicate a flaw in our webapp i.e. it not doing > whatever's necessary to close them and return them to WAITING state. >
[Pantvaidya, Vishwajit] After setting connectionTimeout in tomcat server.xml, the number of open threads is now consistently under 10 and most of them are now in WAITING stage. So looks like connectionTimeout also destroys idle threads. But I am still wondering - why should I have to set connectionTimeout to prevent tomcat running out of threads. I certainly don't mind if the TP-Processor threads continue to hang around as long as they are in WAITING state. 1. Is it expected behavior that most tomcat threads are in RUNNABLE state? 2. If not, does it indicate a problem in the app or in tomcat configuration? My thinking is that the answer to #1 is no, and that to #2 is that it is an app problem. But just wanted to confirm and find out what people out there think. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
