You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Dunlop, Aaron" <aa...@transcore.com> on 2002/12/04 18:32:56 UTC
Thread handling in Tomcat 4.x
Is there any scenario in which Tomcat 4.0 or 4.1 will kill off processor
threads?
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...)
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.
;)
Thanks in advance,
Aaron
-----------------------------------------------------------------------
Aaron Dunlop
Product Development Engineer
TransCore Commercial Services, Inc.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Thread handling in Tomcat 4.x
Posted by bm...@praxid.com.
HI Aaron
The answer to this question is
"Alternatively, is there any error condition under which a thread will be
considered hung or otherwise corrupted and killed off? "
Yes. It does hang , ajp13 connector process(if you use this) will shoot up .
I know one situation that the thread hangs off, during that situation you will
get the catalina
log like this
2002-12-03 21:23:57 Ajp13Processor[8009][0] process: invoke
java.net.SocketException: Connection reset by peer: socket write error
at java.net.SocketOutputStream.socketWrite(Native Method)
at java.net.SocketOutputStream.write(SocketOutputStream.java:83)
at org.apache.ajp.Ajp13.send(Ajp13.java:525)
at org.apache.ajp.RequestHandler.finish(RequestHandler.java:496)
at org.apache.ajp.Ajp13.finish(Ajp13.java:395)
at
org.apache.ajp.tomcat4.Ajp13Response.finishResponse(Ajp13Response.java:192)
at org.apache.ajp.tomcat4.Ajp13Processor.process(Ajp13Processor.java:435)
at org.apache.ajp.tomcat4.Ajp13Processor.run(Ajp13Processor.java:495)
at java.lang.Thread.run(Thread.java:484)
In this situation the process with id 0 is not accessible.
Am searching for the reason why. No answer till now.
Please feel free to share info if we find something
regards
BM
"Dunlop, Aaron" wrote:
> Is there any scenario in which Tomcat 4.0 or 4.1 will kill off processor
> threads?
>
> 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...)
>
> 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.
> ;)
>
> Thanks in advance,
> Aaron
>
> -----------------------------------------------------------------------
> Aaron Dunlop
> Product Development Engineer
> TransCore Commercial Services, Inc.
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
BM
Architect
Praxid Inc
408-941-8306
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Thread handling in Tomcat 4.x
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 4 Dec 2002, Dunlop, Aaron wrote:
> Date: Wed, 4 Dec 2002 09:32:56 -0800
> From: "Dunlop, Aaron" <aa...@transcore.com>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> To: "'tomcat-user@jakarta.apache.org'" <to...@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
>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>