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=21763>. 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=21763 Tomcat 4.1.24 hangs under heavy load using http connector. ------- Additional Comments From [EMAIL PROTECTED] 2003-09-11 17:07 ------- I have sent you guys another full dump of threads. I do not post it here because it has 1500 lines. There are total 129 instances of ControlRunnable (Thread-2 to Thread-130). You will see 125 of them are waiting for monitor entry which is at PoolTcpEndpoint.acceptSocket() which will soon trigger ThreadPool.runIt() -> this.wait(). See it below. "Thread-130" daemon prio=1 tid=0x081af570 nid=0x5c79 waiting for monitor entry [51c4b000..51c4b8b8] at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:351) - waiting to lock <0x44e134e0> (a java.net.PlainSocketImpl) at java.net.ServerSocket.implAccept(ServerSocket.java:448) at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.accept(DashoA6275) at org.apache.tomcat.util.net.jsse.JSSESocketFactory.acceptSocket (JSSESocketFactory.java:240) at org.apache.tomcat.util.net.PoolTcpEndpoint.acceptSocket (PoolTcpEndpoint.java:341) at org.apache.tomcat.util.net.TcpWorkerThread.runIt (PoolTcpEndpoint.java:497) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run (ThreadPool.java:530) at java.lang.Thread.run(Thread.java:534) Only 4 instances are idle listed below. "Thread-127" daemon prio=1 tid=0x081ad0c8 nid=0x5c76 in Object.wait() [51ac8000..51ac88b8] at java.lang.Object.wait(Native Method) - waiting on <0x47acbe10> (a org.apache.tomcat.util.threads.ThreadPool$ControlRunnable) at java.lang.Object.wait(Object.java:429) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run (ThreadPool.java:509) - locked <0x47acbe10> (a org.apache.tomcat.util.threads.ThreadPool$ControlRunnable) at java.lang.Thread.run(Thread.java:534) Obviously, there is another defect in Http Connector that causes too many thread requests on ThreadPool. Once this defect meets the first defect I mentioned above in ThreadPool, which means all (the maxThreads) instances of ControlRunnable are used to wait for listening on the server socket, then all threads will go to the next point at TcpWorkerThread.runIt() -> endpoint.tp.runIt(this) -> ThreadPool.runIt() -> this.wait(), and hang there. I have no idea on how Http Connector works to use threads. I think you guys will find clues from the dump. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
