[ https://issues.apache.org/jira/browse/CURATOR-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14088915#comment-14088915 ]
Cameron McKenzie commented on CURATOR-79: ----------------------------------------- I've made some changes to the unit test and can reproduce the problem. Will look into a fix. I guess that we probably want to either query to see if the node is actually there, or just do a delete to remove it if it is in the case where we get an exception while trying to create the lock node. Will have a think about it. > 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)