tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Funk <funk...@joedog.org>
Subject Re: Different shutdown behavior of httpConnector in TC403 (graceful) and TC406 (reckless)
Date Wed, 04 Jun 2003 15:35:59 GMT
If your need daemon threads to perform some type of cleanup. You'll need to
- 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

Frank.Strecker@arcor.net 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 <funkman@joedog.org>
> 04.06.2003 12:03
> 
> Bitte antworten an "Tomcat Users List" <tomcat-user@jakarta.apache.org>
> An:     Tomcat Users List <tomcat-user@jakarta.apache.org>
> 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
> 
> Frank.Strecker@arcor.net 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: tomcat-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>>
>>
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
> 
> 
> 
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


Mime
View raw message