|Subject:||Re: Thread handling in Tomcat 4.x|
|From:||Craig R. McClanahan (crai...@apache.org)|
|Date:||Dec 4, 2002 12:39:40 pm|
On Wed, 4 Dec 2002, Dunlop, Aaron wrote:
Date: Wed, 4 Dec 2002 09:32:56 -0800 From: "Dunlop, Aaron" <aaro...@transcore.com> Reply-To: Tomcat Users List <tomc...@jakarta.apache.org> To: "'tomc...@jakarta.apache.org'" <tomc...@jakarta.apache.org> Subject: Thread handling in Tomcat 4.x
Is there any scenario in which Tomcat 4.0 or 4.1 will kill off processor threads?
There is no such mechanism currently -- all you can is set the minimum and maximum thread counts (minProcessors and maxProcessors).
I know that under apache, it is possible to limit the number of spare processes, in which case the controller process will kill off extras when load decreases.
Alternatively, is there any error condition under which a thread will be considered hung or otherwise corrupted and killed off?
Our application maps certain objects on a per-thread basis, and I'm worried that we may end up with memory leaks when objects remain referenced in our map even though the thread they are assigned to is no longer valid. (And yes - I know this is probably a bad design, and we're looking into some refactoring there, but not a week before a release if we can avoid it...)
You're right -- this (persistent storage on a per-thread basis) is not a good design for a web application, although temporary storage (for the lifetime of a request in a ThreadLocal) would probably be fine.
The threads belong to the container, not to the app -- and, in fact, they are shared across apps if you're running more than one.
The best place to cache per-app persistent objects, if you need them to stay in memory, is in servlet context attributes (if they are shared) or in a session (if they are specific to a user).
Either there hasn't been any discussion of this topic in the archives or (more likely) I just didn't hit on the right combination of keywords to search on. And I can't convince myself one way or that other from the code. ;)
Short of refactoring, you'd need to patch the way that Coyote manages its thread pool in order to implement a cleanup. I think your time would be better spent on refactoring, though.
Thanks in advance, Aaron