[
https://issues.jboss.org/browse/JGRP-1877?page=com.atlassian.jira.plugin....
]
Bela Ban updated JGRP-1877:
---------------------------
Description:
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}
When computing {{target_time}}, {{System.nanoTime()}} could return a negative value
(numeric overflow) or a value in the future. In the first case, {{target_time}} could be
negative, so the method would not block at all. In the latter case, {{target_time}} could
be huge, so the method would block for a long time.
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_.
was:
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_.
System.nanoTime() may be negative
---------------------------------
Key: JGRP-1877
URL:
https://issues.jboss.org/browse/JGRP-1877
Project: JGroups
Issue Type: Bug
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}
When computing {{target_time}}, {{System.nanoTime()}} could return a negative value
(numeric overflow) or a value in the future. In the first case, {{target_time}} could be
negative, so the method would not block at all. In the latter case, {{target_time}} could
be huge, so the method would block for a long time.
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_.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)