You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@accumulo.apache.org by "Ed Coleman (JIRA)" <ji...@apache.org> on 2016/05/29 02:20:12 UTC
[jira] [Created] (ACCUMULO-4319) Possible synchronization issue in
ZooStore reserve(long tid) method
Ed Coleman created ACCUMULO-4319:
------------------------------------
Summary: Possible synchronization issue in ZooStore reserve(long tid) method
Key: ACCUMULO-4319
URL: https://issues.apache.org/jira/browse/ACCUMULO-4319
Project: Accumulo
Issue Type: Bug
Affects Versions: 1.6.5, 2.0.0
Reporter: Ed Coleman
I am reporting this for investigation - not sure if it is a bug, but from code inspection it seems that the ZooStore reserve(tx_id) can cause a deadlock if it is called while the tx_id is already reserved. From inspection it seems that all methods that remove tx_ids are also synchronized and would block and be unable to remove the tx_id so that the reserve could continue.
I'm not sure this happens and the only way to determine would possible be from logging in the calling code - or by examining stack traces because there is no logging in this method.
The code:
{noformat}
public void reserve(long tid) {
synchronized (this) {
reservationsWaiting++;
try {
while (reserved.contains(tid))
try {
this.wait(1000);
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
reserved.add(tid);
} finally {
reservationsWaiting--;
}
}
}
{noformat}
It seems that a unit test could be created that would deadlock, but that may be synthetic and "never happen", hoping someone knows why and this can just be closed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)