Hi,
Our Tomcat instances are configured to use two Coyote Connectors, one for requests from our SSL accelerator and the other for standard HTTP requests.
We are experiencing problem where after a period of time, anything from 10 minutes to a few days, one of the Connectors stops working. The effected Connector continues to accept incoming requests for a short while but never responds to them. It occurs on both Connectors and, once one has stopped working, typically, the other Connector remains unaffected and continues working normally. The only way to recover from this is for us to restart Tomcat.
We are using Tomcat 4.1.24 running on x86 based dual CPU machines using Red
Hat Linux 9 (kernel 2.4.20-8smp) and using Java Runtime 1.4.1_03.
We have experienced the problem even when the site is under very little load. Inspecting the log files does not show any occurrences of 'All threads are busy' messages. We have set the debug attribute of the Connector to 9 but this has not revealed anything of interest in the logs.
We have generated numerous full thread dumps while the problem is occurring but cannot see anything obvious when examining these and we have used OptimizeIt to analyze our application and we cannot see anything obvious in our application.
Our server.xml file and one of the thread dumps (when the server was under very little load) are at the end of this mail.
Has anyone experienced something similar or perhaps have some comments/suggestions?
Thanks for your attention.
I'm scpetical.
Well, there's not too much wrong with your dump. I'm only wondering about the thread ids which are a bit weird (the gaps are too big). Would you be willing to test TC 5.0.9 or 5.0.10 ? If you're having such stability issues with 4.1, it can't be really worse IMO. There's additional monitoring features (such as the status servlet), which can help investigate.
If you didn't edit the thread dump, then the only explanation I can see so far is that there's a bug with the currentThreadCount variable (and I can see how that would happen). If you can add some traces on the internal ThreadPool variables, that could also help. The structure of the class is relatively simple.
-- xxxxxxxxxxxxxxxxxxxxxxxxxxxxx R�my Maucherat Senior Developer & Consultant JBoss Group (Europe) S�RL xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
