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 17:11:26 UTC
Re: Re: Different shutdown behavior of httpConnector in TC403
(graceful) and TC406 (reckless)
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 <fu...@joedog.org>
04.06.2003 12:03
Bitte antworten an "Tomcat Users List" <to...@jakarta.apache.org>
An: Tomcat Users List <to...@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
Logging help please
Posted by Tim Shaw <ti...@everserve.co.uk>.
Hi,
Does anyone have a link to a FAQ or HOW-TO for using commons-logging
with Tomcat 4.1.x please? I've read the obvious ones at apache.org and
sun.com, and tried all sorts before having to back out and go to a
wrapper around ServletContext.log (which doesn't give me levels and
files etc). I was hoping to use the JDK14 Logger FileLogger.
I'd appreciate a sanity check on the below - thanks for your time.
I have 4 co-operating web apps, each of which extends their Controller
servlet from a class in a common jar file (deployed in WEB-INF/lib with
each app).
I would like to be able to 'tune' (outside the .war file) the logging
levels, filenames etc.
Modifying the $JAVA_HOME/jre/lib/logging.properties file seems to make
no difference (and seems as if it would be 'global').
I tried loading a log properties file using loadResourceAsStream in the
Controller super-class - which seems better (in that it does some of the
logging, but I can't seem to get it to log 'finer' than INFO). This also
creates multiple log files (following the pattern xxxx%u.log as per JDK
1.4 logging). I am happy to provide the properties file-name in the
web.xml as an init parameter - seems sound.
Class Loading etc. :
For singletons (e.g. the Controller servlet super-class instances), I
would assume that initialising the log as a static variable would result
in different Factories for each app as it is a different class-loader.
When I have multiple instances of a class, however, (I'm using
Command/Action pattern) should I use a static variable (write contention
causes the multiple files mentioned above?)? Is there a distinction
between logging to multiple instances of the FileLogger as opposed to a
single instance? Is there a reason to optimise the calls to get a Logger
from the Factory - or is it OK to just grab one as and when?
Sorry for the length.
Regards
tim
---------------------------------------------------------------------
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>.
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 <fu...@joedog.org>
> 04.06.2003 12:03
>
> Bitte antworten an "Tomcat Users List" <to...@jakarta.apache.org>
> An: Tomcat Users List <to...@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