You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Fr...@arcor.net on 2003/06/04 12:07:14 UTC

Different shutdown behavior of httpConnector in TC403 (graceful) and TC406 (reckless)


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


Re: Different shutdown behavior of httpConnector in TC403 (graceful) and TC406 (reckless)

Posted by Tim Funk <fu...@joedog.org>.
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