[jira] [Closed] (CURATOR-206) 2 clients aquired the same InterProcessLock?

["Huahang Liu (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CURATOR-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Huahang Liu closed CURATOR-206.
-------------------------------
    Resolution: Invalid

ConnectionStateListener should be used to monitor state change.


> 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)