-
Bug
-
Resolution: Incomplete
-
P4
-
None
-
8u102
-
x86_64
-
linux
FULL PRODUCT VERSION :
java version "1.8.0_102"
Java(TM) SE Runtime Environment (build 1.8.0_102-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.102-b14, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Linux ubdev 3.16.0-77-generic #99~14.04.1-Ubuntu SMP Tue Jun 28 19:17:10 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
A DESCRIPTION OF THE PROBLEM :
The Timer class has cancel() method, which "Terminates this timer, discarding any currently scheduled tasks.".
What this method does internally is the following:
public void cancel() {
synchronized(queue) {
thread.newTasksMayBeScheduled = false;
queue.clear();
queue.notify(); // In case queue was already empty.
}
}
This looks all fine and matches the documentation. However, note that the Timer never joins its thread (which is a member of type TimerThread).
There is no way for a user of the Timer class to ensure that the thread it starts goes away. The Timer class should provide a method like join() to ensure that the thread is done.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Start a timer (give it a name), call cancel, print all the threads running
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
the threads listed should not include the Timer thread created
ACTUAL -
it sometimes includes the Time thread created
REPRODUCIBILITY :
This bug can be reproduced rarely.
java version "1.8.0_102"
Java(TM) SE Runtime Environment (build 1.8.0_102-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.102-b14, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Linux ubdev 3.16.0-77-generic #99~14.04.1-Ubuntu SMP Tue Jun 28 19:17:10 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
A DESCRIPTION OF THE PROBLEM :
The Timer class has cancel() method, which "Terminates this timer, discarding any currently scheduled tasks.".
What this method does internally is the following:
public void cancel() {
synchronized(queue) {
thread.newTasksMayBeScheduled = false;
queue.clear();
queue.notify(); // In case queue was already empty.
}
}
This looks all fine and matches the documentation. However, note that the Timer never joins its thread (which is a member of type TimerThread).
There is no way for a user of the Timer class to ensure that the thread it starts goes away. The Timer class should provide a method like join() to ensure that the thread is done.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Start a timer (give it a name), call cancel, print all the threads running
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
the threads listed should not include the Timer thread created
ACTUAL -
it sometimes includes the Time thread created
REPRODUCIBILITY :
This bug can be reproduced rarely.