[
https://issues.jboss.org/browse/JGRP-1877?page=com.atlassian.jira.plugin....
]
Bela Ban commented on JGRP-1877:
--------------------------------
Oh, no, can't interrupt the current thread, or else this would result in a busy loop:
if {{done}} is false and we have
{code:java}
catch(InterruptedException e) {
Thread.currentThread().interrupt();
}
{code}
, the loop would continue until {{done}} was false or {{wait_time}} <= 0.
Calling {{cond.wait(wait_time)}} would not wait, but throw an InterruptedException again.
This would busy-loop until {{wait_time}} was <= 0.
It is OK to swallow the InterruptedException as the wait is only supposed to return from
the loop when one or both conditions are met. If the stack is stopped, then cleanup code
makes sure that all pending waits are stopped by setting {{done}} to true.
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_.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)