我能够成功锁定/ads/lock/0-test1
,然后无法锁定/ads/lock
我该如何解决这个问题?
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
...
}
}
更新:这是第250行(详细路径)和299(根路径)中此https://github.com/Microsoft/Cluster-Partition-Rebalancer-For-Kafka/ZookeeperBackedAdoptionLogicImpl.java锁定所发生的事情的本质。因此,当另一个实例尝试锁定详细路径(250)时,锁定失败,因为根路径(299)被锁定。逻辑有效但从未获得根锁
更新2:我写了一个小程序来检查重叠锁是否有效,确实如此。
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");
}
}
}
}
答案 0 :(得分:3)
虽然未明确记录(但请参阅technote 7),但策展人用于创建锁的机制取决于特定znode路径的子节点。 InterProcessMutex
是zookeeper lock recipe的一种实现,其文档包含这些详细信息。通过尝试使用这样的分层结构,你基本上搞乱了锁的内部结构。
锁定路径应被视为"对象"其内部znode无法访问且可能会发生变化。
对更新的回应
有问题的代码确实是这种不当使用的一个例子。
对Update2的回应
是的,它有时可以工作。但这取决于InterProcessMutex
实施的内部细节。您会发现,使用某些锁定名称,这将起作用,而其他锁定名称则不起作用,或者您将有未定义的行为。