3

I was able to successfully get lock on /ads/lock/0-test1 and then couldn't get a lock on /ads/lock

How can I solve this?

InterProcessMutex lock1 = new InterProcessMutex(client, "/ads/lock/0-test1");
if(lock1.acquire(30000, TimeUnit.MILLISECONDS)){
   InterProcessMutex lock2 = new InterProcessMutex(client, "/ads/lock");

   if(lock2.acquire(30000, TimeUnit.MILLISECONDS)) {  //Failing
   ...
   }
}

Update: This is the essence of what's happening in this https://github.com/Microsoft/Cluster-Partition-Rebalancer-For-Kafka/ZookeeperBackedAdoptionLogicImpl.java Locks at line 250(detailed path) and 299(Root path) are sequential. So, when another instance tries the lock a detailed path (250), the lock fails as the root path (299) is locked. The logic is valid but the root lock is never obtained

Update 2: I wrote a small program to check whether overlapping locks work and It does.

public class LockTesting {
    public static final String ROOT_LOCK = "/locks";
    public static final String CHILD_LOCK = ROOT_LOCK+"/child";
    private static CuratorFramework client;

    public static void main(String[] args) throws Exception {

        client = CuratorFrameworkFactory.newClient("127.0.0.1:2181", new ExponentialBackoffRetry(1000, 30));
        client.start();
        InterProcessMutex lock1 = new InterProcessMutex(client, CHILD_LOCK);
        if (lock1.acquire(30000, TimeUnit.MILLISECONDS)) {
            System.out.println("Child Locked");
            InterProcessMutex lock2 = new InterProcessMutex(client, ROOT_LOCK);
            if (lock2.acquire(30000, TimeUnit.MILLISECONDS)) {
                System.out.println("Root Locked");
            }
        }

    }
}
Ansel Zandegran
  • 636
  • 8
  • 18
  • 1
    Please look at Curator Tech Note 7: https://cwiki.apache.org/confluence/display/CURATOR/TN7 - You cannot have overlapping paths like you do in your example. Also, there's no reason for it. Use a different path for the second lock. – Randgalt Jul 06 '17 at 12:48
  • Thank you. But as you see in the Update 2, overlapping locks work. So there is nothing wrong with Microsoft/Cluster-Partition-Rebalancer-For-Kafka. But as you say no reason to use as it is used in the library. – Ansel Zandegran Jul 07 '17 at 07:49
  • Update 2 can still fail. I've now warned you multiple times about having overlapping paths. Please don't do it - Curator does not support it and there's no reason to do it. – Randgalt Jul 07 '17 at 20:07
  • Ansel - can you explain why you keep trying to use overlapping paths like this when it's just as easy to use "/locks/set1" "/locks/set2" etc. There's absolutely no reason to put the child lock in a sub path of the parent lock. – Randgalt Jul 07 '17 at 20:35
  • No reason @Randgait I was just trying the code as it is in the library. Thanks for your advise and I will follow that. – Ansel Zandegran Jul 10 '17 at 07:17

1 Answers1

3

While not documented explicitly (but see technote 7), the mechanisms used by curator to create the lock depend on the child nodes of a particular znode path. The InterProcessMutex is an implementation of the zookeeper lock recipe, whose documentation does include these details. By trying to use a hierarchical construct like this, you are essentially messing with the internal structure of the lock.

The path to lock should be considered an "object" whose internal znodes are inaccessible and subject to change.

Response to Update

The code in question is indeed an example of this inappropriate use.

Response to Update2

Yes, it can sometimes work. But it depends on internal details of the InterProcessMutex implementation. You'll find that with some lock names this will work and with others it will not or you'll have undefined behavior.

Martin Serrano
  • 3,727
  • 1
  • 35
  • 48