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:38:13 GMT


Mike Drob commented on CURATOR-206:

Also, do you see client #0 throwing an exception after reconnect? Even though client #0 thinks
it has the lock, it is likely because it is still stuck in the middle of your endless loop.
If it ever tries to release the lock it will throw an exception.

I imagine that proper use of Curator here would need to verify that you still have the lock
before doing something if there is a chance that that the lock might have expired. Alternatively,
make the locks persistent using something like:

            final InterProcessMutex lock = new InterProcessMutex(client, LOCK_PATH, new StandardLockInternalsDriver()
                public String createsTheLock(CuratorFramework client, String path, byte[]
lockNodeBytes) throws Exception
                    String ourPath;
                    if ( lockNodeBytes != null )
                        ourPath = client.create().creatingParentsIfNeeded().withProtection().withMode(CreateMode.PERSISTENT).forPath(path,
                        ourPath = client.create().creatingParentsIfNeeded().withProtection().withMode(CreateMode.PERSISTENT).forPath(path);
                    return ourPath;

I wonder if this is something that would be good to just have as a standard option.

> 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