I have some more info about the issue that I think is related. I found our Tomcat executable is also establishing a lot of TCP connections. just doing a simple netstat just after I start tomcat and comparing it to when thread count for tomcat reaches 2000, I found a lot more lines like
TCP 127.0.0.1:4912 127.0.0.1:2170 ESTABLISHED 4064 [tomcat5.exe] TCP 127.0.0.1:4912 127.0.0.1:4913 ESTABLISHED 4064 [tomcat5.exe] TCP 127.0.0.1:4913 127.0.0.1:4912 ESTABLISHED 4064 [tomcat5.exe] TCP 127.0.0.1:4914 127.0.0.1:4917 ESTABLISHED 4064 [tomcat5.exe] Is this some sort of tomcat ping? Our tomcat connectors are set up to limit the max http threads as below <Connector port="8080" maxHttpHeaderSize="8192" maxThreads="250" minSpareThreads="25" maxSpareThreads="75" enableLookups="false" redirectPort="8443" acceptCount="100" connectionTimeout="20000" disableUploadTimeout="true" /> <Connector port="8443" maxHttpHeaderSize="8192" maxThreads="100" minSpareThreads="25" maxSpareThreads="50" enableLookups="false" disableUploadTimeout="true" connectionTimeout="20000" acceptCount="100" scheme="https" secure="false" proxyPort="443"/> The only timeouts are for the http requests, are there any other timeouts I can configure that could potentially stop all those selector threads from persisting? ----- Original Message ---- From: "Caldarale, Charles R" <chuck.caldar...@unisys.com> To: Tomcat Users List <users@tomcat.apache.org> Sent: Tuesday, 14 July, 2009 2:59:36 Subject: RE: Tomcat 5.5.23 keeps starting threads until OS runs out of memory > From: Christopher Schultz [mailto:ch...@christopherschultz.net] > Subject: Re: Tomcat 5.5.23 keeps starting threads until OS runs out of > memory > > I'm surprised you're not hitting a thread maximum in the OS > and halting the JVM. I'm not aware of any hard limit in Windows; regardless, hitting such a limit just returns an error status on the system call, not a process abort. > Showing more of the stack trace will certainly help reveal the problem. Not likely; that will only show the stack of the started thread, not where it was started from. A heap profiler should show who created the Thread objects, if the profiler captures enough of the call stack at object creation time. One would think a grep of the webapp source for calls to start() would be a rather quick first cut if a profiler can't be used. If the source isn't available, then one possible way to trap the origin of the Thread.start() call is to enable a security manager and only allow start() calls from Tomcat, not webapp, code. This would probably require several iterations and would be somewhat tedious. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
