accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ed Coleman (JIRA)" <j...@apache.org>
Subject [jira] [Created] (ACCUMULO-4319) Possible synchronization issue in ZooStore reserve(long tid) method
Date Sun, 29 May 2016 02:20:12 GMT
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)

Mime
View raw message