tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 25841] New: - Tomcat/JK thread starvation
Date Wed, 31 Dec 2003 17:06:06 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25841>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25841

Tomcat/JK thread starvation

           Summary: Tomcat/JK thread starvation
           Product: Tomcat 4
           Version: 4.1.24
          Platform: Sun
        OS/Version: Other
            Status: NEW
          Severity: Critical
          Priority: Other
         Component: Connector:JK/AJP (deprecated)
        AssignedTo: tomcat-dev@jakarta.apache.org
        ReportedBy: franz@franzzemen.com


We run Tomcat 4.1.24 out of JBoss 3.2.1.  We have observed that under load, 
tomcat increasing numbers of tomcat threads are "stuck" in a jk conversaton 
with apache (thread dump below).  As max processors is approached and reached, 
this evidently results in decreasing performance for users as they have to wait 
for workers to be available.  Eventually, no response is possible when the 
number of threads in this state is reached and the servers have to be re-
started.  

The doesn't seem to appear except under load - which leaves us to believe that 
its related to max processors.  We have changed max processors from 75 to 100 
to 150.  It takes increasing amounts of concurrency to cause the problem.  
Increasing max processors infinitely is not a solution because we want to 
throttle requests through the appserver using the acceptcount/maxprocessor 
combination.

The thread dump for a typical thread in this condition probably doesn't tell 
you much because it appears to be a perfectly normal situation (until you 
realize that all the threads are "stuck" in this state:

"Thread-334" daemon prio=5 tid=0x19e33c8 nid=0x835 runnable [9ae81000..9ae81994]
	at java.net.SocketInputStream.socketRead0(Native Method)
	at java.net.SocketInputStream.read(SocketInputStream.java:129)
	at java.io.BufferedInputStream.fill(BufferedInputStream.java:183)
	at java.io.BufferedInputStream.read1(BufferedInputStream.java:222)
	at java.io.BufferedInputStream.read(BufferedInputStream.java:277)
	- locked <d170f5f8> (a java.io.BufferedInputStream)
	at org.apache.jk.common.ChannelSocket.read(ChannelSocket.java:498)
	at org.apache.jk.common.ChannelSocket.receive(ChannelSocket.java:436)
	at org.apache.jk.common.ChannelSocket.processConnection
(ChannelSocket.java:551)
	at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:679)
	at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run
(ThreadPool.java:619)
	at java.lang.Thread.run(Thread.java:536)


The connector configuration is:

            <Connector className="org.apache.coyote.tomcat4.CoyoteConnector"
               port="9011" minProcessors="150" maxProcessors="150"
               enableLookups="false"
               acceptCount="50" debug="0" connectionTimeout="60000"
               useURIValidationHack="false"
               protocolHandlerClassName="org.apache.jk.server.JkCoyoteHandler"/>

A typical apache side worker.properties configuration is:

worker.syn1.port=9011
worker.syn1.host=prodapp01.parago.com
worker.syn1.type=ajp13
worker.syn1.cachesize=150
worker.syn1.cache_timeout=600
worker.syn1.lbfactor=100

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