On Wed, 4 Dec 2002, Dunlop, Aaron wrote:
> Date: Wed, 4 Dec 2002 09:32:56 -0800 > From: "Dunlop, Aaron" <[EMAIL PROTECTED]> > Reply-To: Tomcat Users List <[EMAIL PROTECTED]> > To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> > 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 > Craig -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
