]
David Lloyd commented on JGRP-1877:
-----------------------------------
Of course for time periods greater than 292 years, that guarantee is lost.
System.nanoTime() may be in the future
--------------------------------------
Key: JGRP-1877
URL:
https://issues.jboss.org/browse/JGRP-1877
Project: JGroups
Issue Type: Bug
Security Level: Public(Everyone can see)
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.5.1, 3.6
According to the javadoc, {{System.nanoTime()}} should only be used to measure _elapsed
time_, but not compute a _target time in the future_, as {{nanoTime()}} might return a a
time in the future.
Code like the one below might fail:
{code:title=Responses.waitFor()|borderStyle=solid}
public boolean waitFor(long timeout) {
long wait_time;
final long target_time=System.nanoTime() + TimeUnit.NANOSECONDS.convert(timeout,
TimeUnit.MILLISECONDS); // ns
lock.lock();
try {
while(!done && (wait_time=target_time - System.nanoTime()) > 0) {
try {
cond.await(wait_time,TimeUnit.NANOSECONDS);
}
catch(InterruptedException e) {
}
}
return done;
}
finally {
lock.unlock();
}
}
{code}
Investigate all occurrences where we use {{nanoTime()}} to compute a time in the future,
and see what impact a future value value could have. Possibly replace with
{{System.currentTimeMillis()}} or the _time service_.