tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: Thread handling in Tomcat 4.x
Date Wed, 04 Dec 2002 20:40:02 GMT

On Wed, 4 Dec 2002, Dunlop, Aaron wrote:

> Date: Wed, 4 Dec 2002 09:32:56 -0800
> From: "Dunlop, Aaron" <>
> Reply-To: Tomcat Users List <>
> To: "''" <>
> 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


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message