[
https://issues.apache.org/jira/browse/CURATOR-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14490312#comment-14490312
]
Jordan Zimmerman commented on CURATOR-206:
------------------------------------------
Per the Curator documentation, you are required to set a
ConnectionStateListener. When the connection is SUSPENDED or LOST you should
interrupt any locks that you own.
http://curator.apache.org/errors.html
> 2 clients aquired the same InterProcessLock?
> --------------------------------------------
>
> Key: CURATOR-206
> URL: https://issues.apache.org/jira/browse/CURATOR-206
> Project: Apache Curator
> Issue Type: Bug
> Components: Recipes
> Environment: java 1.7 on ubuntu linux
> Reporter: Huahang Liu
>
> When a curator client acquires an InterProcessMutex, it creates an ephemeral
> node on zookeeper. But if we disconnect the network for some time long enough
> so that the ephemeral node expires, the thread that has the lock will not get
> interrupted and still “thinks” it has the lock. And if an other curator
> client tries to acquire the lock with the same path, it will acquired the
> lock while the first client still “thinks” it has the lock.
> Is it a defect? Or is it by design and this is not a proper way to use
> curator?
> The snippet to reproduce this behaviour is uploaded as the following gist:
> https://gist.github.com/huahang/e6ebf948804fd7ea7c13
> Run the code and wait until client #0 gets the lock:
> Client #0 trying to acquire lock
> Client #1 trying to acquire lock
> Client #0 lock acquired
> Disconnect the network and reconnect after the ephemeral node expires, and
> then the following output will show in the command line:
> Client #1 lock acquired
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
