[
https://issues.apache.org/jira/browse/ACCUMULO-4319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ed Coleman updated ACCUMULO-4319:
---------------------------------
Resolution: Not A Problem
Status: Resolved (was: Patch Available)
Created functional IT test for ZooStore that shows this is not a problem.
> 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)
