curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CURATOR-79) InterProcessMutex doesn't clean up after interrupt
Date Mon, 11 Aug 2014 01:28:11 GMT

    [ https://issues.apache.org/jira/browse/CURATOR-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14092320#comment-14092320
] 

ASF GitHub Bot commented on CURATOR-79:
---------------------------------------

GitHub user cammckenzie opened a pull request:

    https://github.com/apache/curator/pull/35

    CURATOR-79 - Modified the 'withProtection' handling, so that any failure

    that is not a ConnectionLossException or other KeeperException is
    treated the same as a ConnectionLossException. This means that if the
    thread gets interrupted, or encounters some sort of other error, during
    creation of a protected zNode, it will remove the affected zNode prior
    to rethrowing the exception.
    
    Exposed the debug UnhandledExceptionListener on the CuratorFrameworkImpl
    to reproduce this issue via a unit test.

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/apache/curator CURATOR-79

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/curator/pull/35.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #35
    
----
commit 5398b72f00ccc0f2ea995865fcaf92d73c6c5818
Author: Cam McKenzie <cammckenzie@apache.org>
Date:   2014-08-10T22:13:12Z

    CURATOR-79 - Modified the 'withProtection' handling, so that any failure
    that is not a ConnectionLossException or other KeeperException is
    treated the same as a ConnectionLossException. This means that if the
    thread gets interrupted, or encounters some sort of other error, during
    creation of a protected zNode, it will remove the affected zNode prior
    to rethrowing the exception.
    
    Exposed the debug UnhandledExceptionListener on the CuratorFrameworkImpl
    to reproduce this issue via a unit test.

----


> InterProcessMutex doesn't clean up after interrupt
> --------------------------------------------------
>
>                 Key: CURATOR-79
>                 URL: https://issues.apache.org/jira/browse/CURATOR-79
>             Project: Apache Curator
>          Issue Type: Bug
>    Affects Versions: 2.0.0-incubating, 2.1.0-incubating, 2.2.0-incubating, 2.3.0
>            Reporter: Orcun Simsek
>            Assignee: Jordan Zimmerman
>
> InterProcessMutex can deadlock if a thread is interrupted during acquire().  Specifically,
CreateBuilderImpl.pathInForeground submits a create request to ZooKeeper, and an InterruptedException
is thrown after the node is created in ZK but before ZK.create returns. ZK.create propagates
a non-KeeperException, so Curator assumes the create has failed, but does not retry, and the
node is now orphaned. At some point in the future, the node becomes the next in the acquisition
sequence, but is not reclaimed as the ZK session has not expired.
> <stack trace attached in comments below>
> Curator should catch the InterruptedException and other non-KeeperExceptions, and delete
the created node before propagating these exceptions.
> (as originally discussed on https://groups.google.com/forum/#!topic/curator-users/9ii5of8SbdQ)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message