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)