I think you mean Curator 2.7.0, right? This sounds similar to CURATOR-71 but I don’t know. Please provide a test case and open an issue in Curator’s Jira.
-Jordan On September 29, 2015 at 3:08:56 AM, Lu, Boying ([email protected]) wrote: Hi, All, We are using ZooKeepr 2.7.0 in our product and we found an issue in our daily testing. This issue is related to the InterProcessMutex.acquire() and I found following stack trace in our log: org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode = NoNode for Sequential path not found: _c_33115fca-5414-40bd-8dfe-baf3ab6f3c5a-lock-0000308430 at org.apache.curator.framework.recipes.locks.StandardLockInternalsDriver.validateOurIndex(StandardLockInternalsDriver.java:81) at org.apache.curator.framework.recipes.locks.StandardLockInternalsDriver.getsTheLock(StandardLockInternalsDriver.java:36) at org.apache.curator.framework.recipes.locks.LockInternals.internalLockLoop(LockInternals.java:278) at org.apache.curator.framework.recipes.locks.LockInternals.attemptLock(LockInternals.java:217) at org.apache.curator.framework.recipes.locks.InterProcessMutex.internalLock(InterProcessMutex.java:232) at org.apache.curator.framework.recipes.locks.InterProcessMutex.acquire(InterProcessMutex.java:108) Reading some codes, I think the root cause maybe related to following snipped (in LockInternals.java:214): try { ourPath = driver.createsTheLock(client, path, localLockNodeBytes); hasTheLock = internalLockLoop(startMillis, millisToWait, ourPath); } My understanding is that the "ourPath" is the full path of the created ephemeral node with a sequential number, But the LockInternals.getSortedChildren() (referenced in the internalLockLoop()) doesn't has any child with such sequential number, so the valid checking fails. Is this an known issue and is there any JIRA to track it? Thanks Boying
