JDK-6336543 : (timer) TimerThread.mainLoop shouldn't ignore InterruptedException for non-daemon Timer threads
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util
  • Affected Version: 5.0u4
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: windows_xp
  • CPU: other
  • Submitted: 2005-10-13
  • Updated: 2010-04-02
  • Resolved: 2007-06-04
Description
OPERATING SYSTEM
Windows XP
FULL JDK VERSION
java version "1.5.0_04"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05)
Java HotSpot(TM) Client VM (build 1.5.0_04-b05, mixed mode)
DESCRIPTION
If a non-daemon java.util.Timer is created then upon JVM shutdown (via destroyJavaVM) the process
will hang until the TimerThread for the Timer has completed; this potentially could be a very long time.
Within an IBM WebSphere environment as part of shutdown remaining threads are interrupted to force
them to shutdown in a timely manner. However the java.util.TimerThread.mainLoop catches and ignores
java.lang.InterruptedException, hence we remain in a hung scenario for long lived Timers.
Removal of catching java.lang.InterruptedException for non-daemon threads would solve this problem.
Comments
EVALUATION Doug Lea writes: I don't think this can be changed. The Timer javadoc explicitly tells people to call cancel to shutdown. People might depend on the fact that cancel is the only way to do it --there's potential for accidental shutdowns if the thread is otherwise interrupted. Which can easily happen: Suppose a task running in a timer registers its thread while waiting for something, and another thread then signals it. (Similar issues hold for java.util.concurrent.ExecutorService.) As a workaround for the submitter for WebSphere, it should not be too hard to write a shutdown hook that would call cancel on existing timers.
14-10-2005