DO NOT REPLY [Bug 28727] - CLOSE_WAIT connections draw 100 % cpu
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=28727. 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=28727 CLOSE_WAIT connections draw 100 % cpu --- Additional Comments From [EMAIL PROTECTED] 2004-10-07 06:56 --- I suggest you try to reproduce first with only 10 or 50 threads. Reproduction would be successful, if you still observe continuous CPU usage in this case, maybe less than 100%, but still noticeable. Then in this state you take a Thread Dump (sending the QUIT signal to the tomcat process). It will write the method stack for all threads inside tomcat to catalina.out. Wait a few seconds an take another Thread Dump, again wait and take a third one. Then look at the stacks of your working threads. Anything special about the top part of the individual stacks? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28727] - CLOSE_WAIT connections draw 100 % cpu
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=28727. 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=28727 CLOSE_WAIT connections draw 100 % cpu --- Additional Comments From [EMAIL PROTECTED] 2004-10-07 09:18 --- Right. Stack traces showing some kind of bad behavior with the Tomcat code would be a start. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28727] - CLOSE_WAIT connections draw 100 % cpu
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=28727. 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=28727 CLOSE_WAIT connections draw 100 % cpu --- Additional Comments From [EMAIL PROTECTED] 2004-10-07 09:54 --- BTW, for that kind of problem, would it be possible to test using the new thread pool from Tomcat 5.5 ? Get Tomcat 5.5.3, and set strategy=ms on the Connector element. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28727] - CLOSE_WAIT connections draw 100 % cpu
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=28727. 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=28727 CLOSE_WAIT connections draw 100 % cpu --- Additional Comments From [EMAIL PROTECTED] 2004-10-06 16:02 --- I can confirm this bug on jakarta-tomcat-5.0.28-embed on Solaris 2.8 Here are my suggestions to reproduce it: - start Tomcat on server S - monitor the status of connections on server S while(1) netstat -a|grep CLOSE_WAIT|wc -l sleep 5 end - establish more than 500 concurrent HTTP connections from client C (We used JMeter to run a work job with 500 threads, 5 requests each) - DETACH THE NETWORK CABLE on client C when you are sure the server is managing at least 500 connections from C - ATTACH THE NETWORK CABLE on client C Expected result: Connections in CLOSE_WAIT status get closed gracefully on server S. Actual Result: Connections in CLOSE_WAIT status never get closed on server S. If you connect to the Tomcat server, response time is very slow. The number of connections in CLOSE_WAIT status keeps growing. Thanks for your time and efforts - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28727] - CLOSE_WAIT connections draw 100 % cpu
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=28727. 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=28727 CLOSE_WAIT connections draw 100 % cpu [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-10-06 16:10 --- I am not really interested in observations on the problem. Please reopen this report only when you can actually prove that Tomcat is at fault. Tomcat will call close on all these sockets. If they are not properly closed for some reason, then there is nothing that can be done here. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28727] - CLOSE_WAIT connections draw 100 % cpu
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=28727. 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=28727 CLOSE_WAIT connections draw 100 % cpu --- Additional Comments From [EMAIL PROTECTED] 2004-10-06 16:38 --- Sorry, I just suggested how to reproduce this bug. That's not observations. As far as Tomcat fault is concerned, let me know which evidence do you need, as a non-responsive Tomcat server draining 100% of cpu is not enough. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28727] - CLOSE_WAIT connections draw 100 % cpu
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=28727. 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=28727 CLOSE_WAIT connections draw 100 % cpu --- Additional Comments From [EMAIL PROTECTED] 2004-10-06 16:48 --- It's obviously not enough. If you cannot point out some flaw with socket handling in Tomcat, or indicate where it would go into a loop, then there's nothing I can fix. Since you're using Solaris, please first make sure you have applied ALL service packs and stuff (Sun fixes Java on Solaris this way). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28727] - CLOSE_WAIT connections draw 100 % cpu
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=28727. 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=28727 CLOSE_WAIT connections draw 100 % cpu --- Additional Comments From [EMAIL PROTECTED] 2004-10-06 18:27 --- The solaris server we use to run Tomcat is up to date. However, the OS field of this bug is Windows XP, so it doesn't seem to be a platform issue. I checked and we do not use a particular SocketFactory, or set any socket params. I believe the Connection pool could lock up itself when too many connections have to be closed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28727] - CLOSE_WAIT connections draw 100 % cpu
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=28727. 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=28727 CLOSE_WAIT connections draw 100 % cpu --- Additional Comments From [EMAIL PROTECTED] 2004-09-30 19:12 --- Please keep us posted ;) I don't want to leave the issue open forever without us being able to reproduce it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28727] - CLOSE_WAIT connections draw 100 % cpu
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=28727. 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=28727 CLOSE_WAIT connections draw 100 % cpu --- Additional Comments From [EMAIL PROTECTED] 2004-09-30 20:31 --- Tomcat calls close on all the sockets, in a very obvious way. After that, if the socket isn't properly closed, then it's a bug in either the VM or the network stack. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28727] - CLOSE_WAIT connections draw 100 % cpu
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=28727. 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=28727 CLOSE_WAIT connections draw 100 % cpu --- Additional Comments From [EMAIL PROTECTED] 2004-09-24 10:41 --- I'm going to switch to Tomcat 5.0.28 embedded. The bug usually shows up in 2/3 days, depending on users activity. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28727] - CLOSE_WAIT connections draw 100 % cpu
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=28727. 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=28727 CLOSE_WAIT connections draw 100 % cpu --- Additional Comments From [EMAIL PROTECTED] 2004-09-23 17:45 --- I can confirm this bug on jakarta-tomcat-5.0.19-embed on Solaris 2.8 Suddenly, CLOSE_WAIT connections start to grow and the whole application which embeds tomcat becomes unresponsive. I understand it is hard to reproduce this bug, but this is a blocker for us. Of course, I can help checking new versions where this issue has been addressed. Platform: SunOS e4500 5.8 Generic_108528-16 sun4u sparc SUNW,Ultra-Enterprise j2re1.4.2_02 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28727] - CLOSE_WAIT connections draw 100 % cpu
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=28727. 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=28727 CLOSE_WAIT connections draw 100 % cpu --- Additional Comments From [EMAIL PROTECTED] 2004-09-23 17:47 --- Well, then please try newer versions than 5.0.19 ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28727] - CLOSE_WAIT connections draw 100 % cpu
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=28727. 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=28727 CLOSE_WAIT connections draw 100 % cpu [EMAIL PROTECTED] changed: What|Removed |Added Severity|Blocker |Normal --- Additional Comments From [EMAIL PROTECTED] 2004-09-15 18:18 --- Can you also please try Tomcat 5.0.28 and the latest connector binary (1.2.6 for mod_jk)? I'm downgrading this from a Blocker severity to normal, as no one else has complaind, and we haven't been able to reproduce it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28727] - CLOSE_WAIT connections draw 100 % cpu
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=28727. 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=28727 CLOSE_WAIT connections draw 100 % cpu [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2004-08-19 01:45 --- I'm experiencing something similar I believe using Tomcat 5.0.27 on an application server that's proxied over from another (Apache) web front-end. The application runs fine for a time, but quickly CLOSE_WAIT connections to the Apache server start building up and the TC5 server becomes completely non-responsive. truss-ing the Tomcat process reveals some sort of looping activity: /88:lwp_mutex_lock(0x000EC290) (sleeping...) /111: lwp_mutex_lock(0x000EC290) (sleeping...) /65:lwp_cond_wait(0x0078EE88, 0x0078EE70, 0x) (sleeping...) /84:lwp_mutex_lock(0x000EC290) (sleeping...) /9: lwp_cond_wait(0x0002D020, 0x0002D008, 0x) (sleeping...) /141: lwp_mutex_lock(0x000EC290) (sleeping...) /25:lwp_mutex_lock(0x000EC290) (sleeping...) /118: lwp_mutex_lock(0x000EC290) (sleeping...) /60:lwp_cond_wait(0x00D4DDF0, 0x00D4DDD8, 0x) (sleeping...) /42:lwp_cond_wait(0x003FF4A8, 0x003FF490, 0xEE9FF7F0) (sleeping...) /68:lwp_cond_wait(0x00791258, 0x00791240, 0xECFFF7F0) (sleeping...) /61:lwp_cond_wait(0x00D4E4A0, 0x00D4E488, 0x) (sleeping...) /158: lwp_mutex_lock(0x000EC290) (sleeping...) /107: lwp_mutex_lock(0x000EC290) (sleeping...) /22:lwp_mutex_lock(0x000EC290) (sleeping...) /112: lwp_mutex_lock(0x000EC290) (sleeping...) /71:lwp_mutex_lock(0x000EC290) (sleeping...) /183: lwp_mutex_lock(0x000EC290) (sleeping...) /54:lwp_cond_wait(0x0045D220, 0x0045D208, 0x) (sleeping...) /16:lwp_mutex_lock(0x000EC290) (sleeping...) /144: lwp_mutex_lock(0x000EC290) (sleeping...) /114: lwp_mutex_lock(0x000EC290) (sleeping...) /23:lwp_mutex_lock(0x000EC290) (sleeping...) followed by many lines of : /10:poll(0xF98FFD58, 0, 50) = 0 /2: lwp_cond_wait(0x0002CB80, 0x0002CB68, 0xFC77FD30) Err#62 ETIME During this time, Tomcat is apparently sleeping, and completely non-responsive. A restart results in the server responding again for a short time, then going back into the same state. Apache 1.3.27 on web server, using ProxyPass to the application server, Solaris 9 OS, JVM 1.4.2_04. Tomcat version 5.0.27. Any pointers would be appreciated. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
