Re: Scripted shutdown does not force JVM exit
Both JBoss and Jetty force a proper shutdown. I'll probably go for 2/ and patch for myself. Cheers Brett --- QM <[EMAIL PROTECTED]> 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: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > Find local movie times and trailers on Yahoo! Movies. http://au.movies.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Scripted shutdown does not force JVM exit
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Scripted shutdown does not force JVM exit
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Scripted shutdown does not force JVM exit
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Scripted shutdown does not force JVM exit
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Scripted shutdown does not force JVM exit
This email [EMAIL PROTECTED] is no longer available due to heavy spamming. Please visit our website http://www.alestron.com for contact info. Thank you! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Scripted shutdown does not force JVM exit
This email [EMAIL PROTECTED] is no longer available due to heavy spamming. Please visit our website http://www.alestron.com for contact info. Thank you! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]