tag:blogger.com,1999:blog-3237724005744642470.post191850808093819680..comments2020-05-08T12:31:27.297+01:00Comments on Captain Debug's Blog: Tomcat's Graceful Shutdown with Daemons and Shutdown HooksRoger Hugheshttp://www.blogger.com/profile/07042290171112551665[email protected]Blogger4125tag:blogger.com,1999:blog-3237724005744642470.post-20543547603342749652013-09-29T09:42:33.480+01:002013-09-29T09:42:33.480+01:00Unknown,
I thought that I'd try you idea of us...<br />Unknown,<br />I thought that I'd try you idea of using Thread.interrupted() or Thread.currentThread().isInterrupted() as it sounds rather plausible. Unfortunately, it doesn't work as the status of a threads interrupted flag after the thread.interrupt() call depends upon how the thread is blocking.<br /><br />From the JavaDocs for Thread.interrupt(): "If this thread is blocked in an invocation of the wait(), wait(long), or wait(long, int) methods of the Object class, or of the join(),join(long), join(long, int), sleep(long), or sleep(long, int), methods of this class, then its interrupt status will be cleared and it will receive an InterruptedException.<br />If this thread is blocked in an I/O operation upon an interruptible channel then the channel will be closed, the thread's interrupt status will be set, and the thread will receive a ClosedByInterruptException."<br />In my example, the thread will be blocking using thread.sleep(…) and therefore the flag will be cleared and any subsequent test of thread.isInterrupted() will return false. Therefore the idea will only work if you can guarantee that a thread is blocking on an I/O operation when you call thread.interrupt().<br />Roger Hugheshttps://www.blogger.com/profile/07042290171112551665[email protected]tag:blogger.com,1999:blog-3237724005744642470.post-59747918859787459072013-09-26T13:50:44.031+01:002013-09-26T13:50:44.031+01:00Hello,
Well remembered, I've seen more than on...Hello,<br />Well remembered, I've seen more than one application locking the app server on shutdown, typically when there was some batch(-ish) work to do.<br />I think you can remove the dependency between the workers (DeferredResultService and MatchReporter) and the Hook if they used <a href="http://docs.oracle.com/javase/7/docs/api/java/lang/Thread.html#interrupted()" rel="nofollow">Thread.interrupted</a> or <a href="http://docs.oracle.com/javase/7/docs/api/java/lang/Thread.html#isInterrupted()" rel="nofollow">Thread.currentThread().isInterrupted</a> as the termination condition.<br />Just as a quick note, it's also possible to do the association of threads and hooks in a <a href="http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ThreadFactory.html" rel="nofollow">ThreadFactory</a> used by a <a href="http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ThreadPoolExecutor.html" rel="nofollow">ThreadPoolExecutor</a>, which is injected in the worker instances so that they submit themselves to it, and then have the shutdown hook call <a href="http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ThreadPoolExecutor.html#shutdownNow()" rel="nofollow">shutdownNow()</a> on the pool.<br />I understand that if the article used any of this it would probably get a bit too complicated and miss the central point, though. But I though I should just mention it.Unknownhttps://www.blogger.com/profile/12970646863861857923[email protected]tag:blogger.com,1999:blog-3237724005744642470.post-6627330709911835172013-09-26T07:50:36.208+01:002013-09-26T07:50:36.208+01:00Hi,
Thanks for the comment. This technique will wo...Hi,<br />Thanks for the comment. This technique will work for any multi-threaded Java application, including Jetty.Roger Hugheshttps://www.blogger.com/profile/07042290171112551665[email protected]tag:blogger.com,1999:blog-3237724005744642470.post-3244554320150771142013-09-26T06:27:11.130+01:002013-09-26T06:27:11.130+01:00Great aritcle, but this hook works with other serv...Great aritcle, but this hook works with other servlet engines (like Jetty for example) ?Anonymous[email protected]