-
Bug
-
Resolution: Fixed
-
Critical
-
None
It happens, because "wait(timeout)" is not in the loop. Object#wait(long) is explicit about that: "A thread can also wake up without being notified, interrupted, or timing out, a so-called spurious wakeup. While this will rarely occur in practice, applications must guard against it by testing for the condition that should have caused the thread to be awakened, and continuing to wait if the condition is not satisfied. In other words, waits should always occur in loops..."
https://docs.oracle.com/javase/8/docs/api/java/lang/Object.html#wait-long-
Impact:
- AsyncFutureImpl is being used explicitly in JarCacheSupport. Jar resolution with a timeout may fail due to the issue
- The class is overridden in Jenkins Core's public API, e.g. hudson.model.queue.FutureImpl. It's hard to estimate risks, but it looks bad.
- is related to
-
JENKINS-20947 Failed to monitor for Free Swap Space
-
- Open
-
- links to
Code changed in jenkins
User: Oleg Nenashev
Path:
src/main/java/hudson/remoting/AsyncFutureImpl.java
http://jenkins-ci.org/commit/remoting/3f07563743ef1874057eeb17e04847170436b39f
Log:
JENKINS-48309- Prevent TimeoutException in AsyncFutureImpl in the case of spurious wakeups (#240)JENKINS-48309- Prevent TimeoutException in AsyncFutureImpl in the case of spurious wakeups.TL;DR: A large part of Jenkins’ get-with-timeout logic is a subject for improper exit before the timeout.
JENKINS-48309- I was too lazy to use nanos in the beginning, address the comment from @stephencJENKINS-48309- Use wait with nanos in hope there are Java implementations which really support nano timeouts.JENKINS-48309- And again, @stephenc prevents a major embarassement due to the stupid typo