Tomcat 6.0.20 Threads Not closing

[Piyush Jain]

I have the following setup in the server.xml file:

 <Executor name="tomcatThreadPool" namePrefix="catalina-exec-"
        maxThreads="50" minSpareThreads="5" maxSpareThreads="10"/>
        
        <Connector connectionTimeout="20000" executor="tomcatThreadPool"
          port="8080" protocol="HTTP/1.1" redirectPort="8443"/>

I want the Tomcat threads to come down to 5 or 10 if there are no requests to the server. However, when I started firing requests to the server, and it reached 15, it never came down. I looked at the "Status" page in the Tomcat Manager application, and the current thread count remains 15, never comes down.

Is there anything that I missed in the above configuration? What am I doing wrong here?

[William Brogden]

Why do you want the number of Threads to come down?

It is just a pool of Thread objects which the container has available to assign to incoming requests. Having a pool saves the time involved in Thread object creationl The amount of system resources involved in keeping that pool is minimal.

Those settings allow you to make a good guess as to what will probably be needed. I have never run a copy of Tomcat that actually cuts the thread pool down so I suspect the "maxSpareThreads" does not operate to remove Threads from the pool.

Bill

[Piyush Jain]

We are having a "too many open files" problem in production, which might be caused by too many threads opened from tomcat. One of the deployed apps is a middleware which is a proxy for handling a large number of requests (each servlet request makes couple of network calls). During large loads this is throwing a "java.net.socket" exception and the application stops working after that. I checked for open files with "lsof" and sometimes the number reaches "1900" and stays there even after the requests have stopped.

So I am assuming bringing down the open connections should help solve this problem.

However, there might be leaks somewhere else in the application i.e., unclosed network connections etc., but so far I haven't been able to find any. I am printing debug statements and making sure all network calls are closed after completion.

[William Brogden]

So I am assuming bringing down the open connections should help solve this problem.

Bad assumption. If your code is not correctly closing handles, limiting the number of Threads in the thread pool will have no magic effect.

Those pool Threads are no longer connected to any request processing so deleting them will not affect your problem.

Bill

[Piyush Jain]

What would be the best way to find out if there are any unclosed handles?

jconsole? How would I know whether I am looking at Tomcat threads of my own application threads?

[neil upfalow]

i'm curious about this too for a slightly different reason. one thing i noticed is you have timeout of 20000.
most tuning topics n vids indicate if apache is front ending the requests that you can bring the timeout down to say 300...since there is no reason to maintain the connection as apache is doing that w the browser. perhaps you won't see threads dying until that 20000secs have elapsed....whic his a pretty long time. 300s is 5m.

i do see our tomcat 5.5 systems reduce threadcount. To me it appears in a monitorng program that shows tomcat threads as processes.

if anyone knows, i'd love to know an answer i have on another topic i started about threads/procs. I'd like to run no more than are needed. If the hardware only has 24 cores and the normal request work is done n complete within 100ms or so, what do i need more than even 24 threads / procs? I ask because with many VEs running tomcat the total threads grows to a ridiculous number and very few seem to accumulate cpu time with the rest just always in a sleeping state.