JDK-6725789 : ScheduledExecutorService does not work as expected in jdk7/6/5
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util.concurrent
  • Affected Version: 7
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2008-07-15
  • Updated: 2010-12-11
  • Resolved: 2010-12-11
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other Other JDK 6 JDK 7
5.0u16-revFixed 5.0u18Fixed 6u20-revFixed 7 b34Fixed
Related Reports
Relates :  
ScheduledExecutorService does not work as we expect.

The test programs schedules the execution of MyTask().
When Mytask() is scheduled  in scheduleWithFixedDelay() as follows,
 -initialDelay is 0 : Execute right now
 -delay is 1000[msec] : Execute every 1000[msec]
the MyTask() sometimes is not executed.
Initial execution of MyTask() is not executed and scheduled MyTask() is not executed also.

OS : WindowsXP(SP2,Japanese)
JRE/JDK : jdk7b30/jdk6u7/jdk5u16

 The reporter says, this occus in RHEL(x86) and submitter confirms this problem occurs in Solaris10.

 The problem can be reproducible so often. 
The test program sometimes finishes correctly.

 The followings message will shows up.

 No message. The execution seems hang.

EVALUATION http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f33c3846cecb

EVALUATION There is actually a more subtle underlying issue with the data structure that hides a number of potential bugs. Martin Buchholz has prepared a complete fix for delivery in to OpenJDK.

SUGGESTED FIX if (triggerTime < 0) triggerTime = Long.MAX_VALUE;

EVALUATION As the submitter had determined the various "schedule" methods contain code of the form: long triggerTime = now() + delay; and if the delay is sufficiently large then overflow will occur. When overflow occurs a negative delay-time can be stored into the delay-queue and this causes the delay queue to operate incorrectly. If you place a correct entry in the queue and then add a negative entry, while the correct entry is still there, then the correct entry is pushed down and no task ever becomes scheduled to run - and we have the hang as reported. However, if the correct task is removed from the queue by a worker thread, prior to the negative task being submitted, then the task is correctly replaced in the queue and the test passes. It was curious to find that: java Test passes, while java -showversion Test always hangs.

WORK AROUND Avoid using delays far in the future.