]
David Lloyd commented on JGRP-1877:
-----------------------------------
Using {{currentTimeMillis()}} might give you trouble if/when the system clock is adjusted
for NTP or whatever.
A simple workaround is to keep a "start" time like this:
{code}
private static final long START_TIME = System.nanoTime();
public static long getCurrentRelativeTime() {
return System.nanoTime() - START_TIME;
}
{code}
This works for time periods over a century long and will give you the precise time since
that class was initialized, as an effectively-always-positive long value.
System.nanoTime() may be negative
---------------------------------
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
negative value.
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 negative value could have. Possibly replace with
{{System.currentTimeMillis()}} or the _time service_.