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 21:56:15 GMT

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

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

Github user cammckenzie commented on a diff in the pull request:

    https://github.com/apache/curator/pull/35#discussion_r16083287
  
    --- Diff: curator-framework/src/main/java/org/apache/curator/framework/imps/CreateBuilderImpl.java
---
    @@ -469,6 +469,26 @@ private String protectedPathInForeground(String adjustedPath, byte[]
data) throw
                 }
                 throw e;
             }
    +        catch ( KeeperException e )
    +        {
    +            throw e;
    +        }
    +        catch ( Exception e )
    +        {
    +            if ( protectedId != null )
    +            {
    +                /*
    +                 * CURATOR-79 - Handle an runtime exception's here and treat the
    +                 * same as a connection loss exception. This is necessary as, from
    +                 * the clients point of view, an exception has been thrown and the
    +                 * zNode should not exist on ZK. This was causing deadlock in the
    +                 * locking recipes.
    +                 */
    +                findAndDeleteProtectedNodeInBackground(adjustedPath, protectedId, null);
    +                protectedId = UUID.randomUUID().toString();
    --- End diff --
    
    I don't think there's a race condition given that the findAndDeleteProtectionNodeInBackground
is being passed a reference to the ID it needs to delete. I will change to assign to a local
variable and pass this to the findAndDeleteProtectionNodeInBackground method for clarity.



> 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