curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Drob (JIRA)" <>
Subject [jira] [Commented] (CURATOR-206) 2 clients aquired the same InterProcessLock?
Date Fri, 10 Apr 2015 19:04:12 GMT


Mike Drob commented on CURATOR-206:

It's fine for a different client to acquire the lock after the ephemeral node expires. You
don't see any messages about client #0 releasing the lock, though?

> 2 clients aquired the same InterProcessLock?
> --------------------------------------------
>                 Key: CURATOR-206
>                 URL:
>             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: 
> 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

View raw message