[
https://issues.apache.org/jira/browse/CURATOR-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Huahang Liu updated CURATOR-206:
--------------------------------
Description:
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 this 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
was:
2 clients acquired the same InterProcessMutex?
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 this 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
> 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 this 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)
