Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jira@apache.org
Date: Mon, 30 May 2016 21:01:12 +0000 (UTC)
From: "Ed Coleman (JIRA)" <jira@apache.org>
To: notifications@accumulo.apache.org
Message-ID: <JIRA.12973747.1464488392000.333012.1464642072832@Atlassian.JIRA>
In-Reply-To: <JIRA.12973747.1464488392000@Atlassian.JIRA>
References: <JIRA.12973747.1464488392000@Atlassian.JIRA> <JIRA.12973747.1464488392744@arcas>
Subject: [jira] [Updated] (ACCUMULO-4319) Possible synchronization issue in
 ZooStore reserve(long tid) method
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Mon, 30 May 2016 21:01:15 -0000


     [ https://issues.apache.org/jira/browse/ACCUMULO-4319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ed Coleman updated ACCUMULO-4319:
---------------------------------
    Status: Patch Available  (was: Open)

Patch with functional IT test for ZooStore shows that this is not an issue.

> 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
>         Attachments: ACCUMULO-4319-tests.patch
>
>
> 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)