- Create a non-deamon thread for the sole purpose of ensuring the JVM stays up
- Create a LifeCycleListener (or other appropriate listener) to listen for tomcat startup and shutdown events
- On shutdown, you'll need a synching method to kill the non-daemon thread once it knows all the daemon threads are done doing their thing
-Tim
[EMAIL PROTECTED] wrote:
Okay, I see that point. Since the worker threads who perform the very work to respond a request are deamons, there seems to be a hard and unconfigured timeout effective in TC406.
TC403 and TC406 show different behaviors when stopping. Both would require certain application coding, but which one is the correct behavior, that application programmers should rely on?
Tim Funk <[EMAIL PROTECTED]> 04.06.2003 12:03
Bitte antworten an "Tomcat Users List" <[EMAIL PROTECTED]> An: Tomcat Users List <[EMAIL PROTECTED]> Kopie: Thema: Re: Different shutdown behavior of httpConnector in TC403 (graceful) and TC406 (reckless)
There isn't any code (that I know of) in 4.0.6 that performs the kill.
The JVM will terminate if "only daemon threads are running". If the daemon threads need to perform more work during a shutdown, you need to make sure one of them is non-daemon.
-Tim
[EMAIL PROTECTED] wrote:
When shutdown.sh is launched, TC performs a stop on all HttpConnectors, which themselves will stop their HttpProcessors.
It seems to that - while TC 403 waits "gracefully" for the work on a request
to
be finished (even forever) - TC 406 will wait 5 secs only and then shutdown without any respect to the work done in the processors background threads.
I am afraid both ways can have undesired consequences. TC 403 will sometimes simply resist to shut down, while in a TC406 shutdown the work done in daemon threads will be interrupted without regards to the current states of the threads.
The behavior of TC 406 is fine when there are only requests that can be
handled
fast. On the other hand, with large transactions I would prefer the behavior
of
TC 403 and pervent the requests from lasting too long by implementing configurable timeouts myself in the application code. Otherwise - or as it
seems
to be implemented in TC406 - we would risk to interrupt vulnerable operations, aren't we?
So, my primary question is this one: Did I overlook a point, in particular: Is there a way to configure the shutdown behavior in TC 406 top wait for the background threads to finish?
There was discussion on that topic last year ( http://marc.theaimsgroup.com/?t=104454190600001&r=1&w=2), but I do not see where it had practical consequences in the code.
Thanks
Frank
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
