tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <r...@apache.org>
Subject Re: DO NOT REPLY [Bug 32262] New: - Possible deadlock in TcpWorkerThread and ThreadPool
Date Tue, 16 Nov 2004 12:20:39 GMT
bugzilla@apache.org wrote:

>DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
>RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
><http://issues.apache.org/bugzilla/show_bug.cgi?id=32262>.
>ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
>INSERTED IN THE BUG DATABASE.
>
>http://issues.apache.org/bugzilla/show_bug.cgi?id=32262
>
>           Summary: Possible deadlock in TcpWorkerThread and ThreadPool
>           Product: Tomcat 5
>           Version: 5.0.29
>          Platform: PC
>        OS/Version: Linux
>            Status: UNCONFIRMED
>          Severity: major
>          Priority: P2
>         Component: Connector:Coyote
>        AssignedTo: tomcat-dev@jakarta.apache.org
>        ReportedBy: frederic.bages@123multimedia.com
>
>
>Recently we got the following message "SEVERE: Caught exception 
>(java.lang.OutOfMemoryError: unable to create new native thread) executing 
>org.apache.tomcat.util.net.TcpWorkerThread@7effa5, terminating thread". Tomcat 
>stopped responding to request but was still alive. This message comes from the 
>ThreadPool class 
>(jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/ThreadPool.java) 
>when an exception is received. This exception comes from the TcpWorkerThread 
>and is an OutOfMemoryError. I don't know exactly where this exception is 
>thrown but it could be from these lines : 
>
Ok, so BZ is down.

I never fully understood how this particular thread pool strategy worked 
(it dates back to Tomcat 3). So for fixing it if somehow it's broken, I 
don't know.

In Tomcat 5.5, I ported back the thread pool strategy from Tomcat 4.0. 
Although it does a little more synchronization (which IMO shouldn't add 
any measurable overhead), it is also much simpler to understand, 
profile, tweak thread priority, etc, as it uses the usual pattern of 
having one (or more, although it's not implemented and I don't really 
see the point) master thread which does the accept on the server socket, 
and a pool of processing threads to process the accepted sockets. To try 
out that, get TC 5.5.4, and add strategy="ms" on the Connector element 
for the HTTP connector.

Rémy


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message