tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <>
Subject Re: Tomcat 4.1.24 Coyote Connector hangs
Date Fri, 05 Sep 2003 19:39:19 GMT wrote:

> 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.

Rémy Maucherat
Senior Developer & Consultant
JBoss Group (Europe) SàRL

View raw message