You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Brett Randall <br...@yahoo.com.au> on 2005/01/01 09:45:52 UTC
Scripted shutdown does not force JVM exit
I've noticed that Tomcat's scripted/orderly shutdown does not force the
JVM to exit. After running all lifecycle events, the main thread just
"falls-through" rather than calling exit(0) to end the JVM.
I'm wondering if this is intentional? The result is that any
application-spawned Thread-s that are not well managed (i.e. are allowed
to continue to run or block after the context is removed) continue to
run, and the JVM does not exit.
This presents a problem for application deployers, when faced with
applications that spawn threads and do not clean them up. The only
shutdown option in these cases is to send a SIGINTR to the JVM, as the
scripted shutdown does not call exit.
Is there a major problem with having the Tomcat shutdown sequence make a
final call of System.exit(0), perhaps as a configurable option? I think
that if the intention is to shutdown the container, it makes sense that
any (now defunct) threads that applications spawned also end. I suppose
that this would be a problem for anyone who runs Tomcat in a shared JVM.
Opinions please.
Brett Randall
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Scripted shutdown does not force JVM exit
Posted by Brett Randall <br...@yahoo.com.au>.
Both JBoss and Jetty force a proper shutdown. I'll
probably go for 2/ and patch for myself.
Cheers
Brett
--- QM <qm...@brandxdev.net> wrote:
> On Sun, Jan 02, 2005 at 10:10:02AM +1100, Brett
> Randall wrote:
> : Yes, responsibility has been placed on developers
> and
> : architects, but a Tomcat admin who deploys
> : applications may not be in a position to hold them
> all
> : individually to account.
>
> This is a policy/political problem, then, and not a
> technology issue.
> If developers push sloppy, cranky code into a
> production environment and
> they're not held accountable for the results,
> well...
>
> Options:
>
> 1/ replace the offending developers with people who
> understand and
> follow best practices. Supplement this crew with a
> rigorous testing/QA
> phase to smoke out any honest mistakes.
> (If this is a vended/third-party app, put pressure
> on the vendor.)
>
> 2/ Do a CVS pull and use/distribute your own
> "Thread-Cleanup Tomcat."
> (Sounds like you already know where to make your
> change.)
>
> 3/ Try to sway the Tomcat developers into folding #2
> into the mainline
> code.
> (Good luck.)
>
> Should #3 pass, I suspect the next request would be
> for a "JDBC
> connection cleanup Tomcat" ;)
>
> -QM
>
>
> --
>
> software -- http://www.brandxdev.net
> tech news -- http://www.RoarNetworX.com
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> tomcat-user-help@jakarta.apache.org
>
>
Find local movie times and trailers on Yahoo! Movies.
http://au.movies.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Scripted shutdown does not force JVM exit
Posted by QM <qm...@brandxdev.net>.
On Sun, Jan 02, 2005 at 10:10:02AM +1100, Brett Randall wrote:
: Yes, responsibility has been placed on developers and
: architects, but a Tomcat admin who deploys
: applications may not be in a position to hold them all
: individually to account.
This is a policy/political problem, then, and not a technology issue.
If developers push sloppy, cranky code into a production environment and
they're not held accountable for the results, well...
Options:
1/ replace the offending developers with people who understand and
follow best practices. Supplement this crew with a rigorous testing/QA
phase to smoke out any honest mistakes.
(If this is a vended/third-party app, put pressure on the vendor.)
2/ Do a CVS pull and use/distribute your own "Thread-Cleanup Tomcat."
(Sounds like you already know where to make your change.)
3/ Try to sway the Tomcat developers into folding #2 into the mainline
code.
(Good luck.)
Should #3 pass, I suspect the next request would be for a "JDBC
connection cleanup Tomcat" ;)
-QM
--
software -- http://www.brandxdev.net
tech news -- http://www.RoarNetworX.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Scripted shutdown does not force JVM exit
Posted by Brett Randall <br...@yahoo.com.au>.
Hi Tim, QM, thanks for your replies.
Tim Funk:
> Calling System.exit() has been discussed on
tomcat-dev and by vetoed.
Yes, thanks, I subsequently found zilla 17000 and the
discussion.
Tim Funk:
> If the JVM does not shut down - it is due to bad 3rd
party code which creates non-daemon threads and fail
to detect a shutdown.
As put in my original post, I totally agree that it is
bad form by the webapp to start a long-running Thread
and not shut it down during its own shutdown.
QM:
> I'd disagree; it puts responsibility on developers
and architects to make sure their applications handle
threads properly.
Yes, responsibility has been placed on developers and
architects, but a Tomcat admin who deploys
applications may not be in a position to hold them all
individually to account.
Tim Funk:
> Then if you need to kill the JVM - just "kill -9
`cat $CATALINA_PID`"
Yes, bearing in mind that SIGKILL is a very blunt
instrument. It will prevent the JVM from running any
shutdown hooks or finalizers. SIGHUP seems to work OK
on Linux, but the way the JVM responds to signals from
the OS seems to vary. For this reason, I think
"killing from the outside" is bad and should be
avoided if at all possible.
QM:
> There's no need for a container to compensate for
poor design. =)
Agreed, but wouldn't you agree that said poor design
of a webapp should not cause (unnecessary) problems
with administration of the container? Important to
remember that not all Tomcat admins write the webapp
code. Source code is often not available.
I think this can be argued from the other perspective:
the container is already compensating for poor design
in the webapp, by allowing stray threads to continue
running. Shutdown means shutdown, which should give
the container the right to terminate the JVM, no?
***
Note that the shutdown sequence in a default 3.2.x
jBoss deployment does finally shutdown the JVM.
+1 for the (configurable) enhancement described in
17000, based on the fact that System.exit(0) is better
than "killing from the outside", in circumstances
beyond the Tomcat Administrator's control (when a
webapp misbehaves by leaving unterminated threads). I
see no good reason to delegate this part of the
shutdown sequence to the operating system.
Happy to see any arguments for -1.
Regards
Brett Randall
Find local movie times and trailers on Yahoo! Movies.
http://au.movies.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Scripted shutdown does not force JVM exit
Posted by Tim Funk <fu...@joedog.org>.
The JVM exits when there are 0 non-daemon threads running. Tomcat itself
shuts down fine with this constraint.
If the JVM does not shut down - it is due to bad 3rd party code which creates
non-daemon threads and fail to detect a shutdown.
The UNIX scripts allow you to capture the process id of the JVM. This is done
by setting the environment variable CATALINA_PID to be some file name. Then
if you need to kill the JVM - just "kill -9 `cat $CATALINA_PID`"
Calling System.exit() has been discussed on tomcat-dev and by vetoed.
-Tim
Brett Randall wrote:
> I've noticed that Tomcat's scripted/orderly shutdown does not force the
> JVM to exit. After running all lifecycle events, the main thread just
> "falls-through" rather than calling exit(0) to end the JVM.
>
> I'm wondering if this is intentional? The result is that any
> application-spawned Thread-s that are not well managed (i.e. are allowed
> to continue to run or block after the context is removed) continue to
> run, and the JVM does not exit.
>
> This presents a problem for application deployers, when faced with
> applications that spawn threads and do not clean them up. The only
> shutdown option in these cases is to send a SIGINTR to the JVM, as the
> scripted shutdown does not call exit.
>
> Is there a major problem with having the Tomcat shutdown sequence make a
> final call of System.exit(0), perhaps as a configurable option? I think
> that if the intention is to shutdown the container, it makes sense that
> any (now defunct) threads that applications spawned also end. I suppose
> that this would be a problem for anyone who runs Tomcat in a shared JVM.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Scripted shutdown does not force JVM exit
Posted by QM <qm...@brandxdev.net>.
On Sat, Jan 01, 2005 at 07:45:52PM +1100, Brett Randall wrote:
: I'm wondering if this is intentional? The result is that any
: application-spawned Thread-s that are not well managed (i.e. are allowed
: to continue to run or block after the context is removed) continue to
: run, and the JVM does not exit.
Yes. This has been discussed several times before; see the archives for
details.
: This presents a problem for application deployers, when faced with
: applications that spawn threads and do not clean them up. The only
: shutdown option in these cases is to send a SIGINTR to the JVM, as the
: scripted shutdown does not call exit.
I'd disagree; it puts responsibility on developers and architects to
make sure their applications handle threads properly. There's no need
for a container to compensate for poor design. =)
Think of "Tomcat hanging on shutdown" as a clue that someone hasn't
cleaned up their threads.
-QM
--
software -- http://www.brandxdev.net
tech news -- http://www.RoarNetworX.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org