As is stated in the Curator documentation (see: http://curator.apache.org/errors.html <http://curator.apache.org/errors.html>) you should assume that your locks are no longer valid when the connection is lost/suspended. If you get SUSPENDED or LOST you should interrupt your locks and consider them lost. For recipes like LeaderSelector, this is done for you (see: https://github.com/apache/curator/blob/master/curator-recipes/src/main/java/org/apache/curator/framework/recipes/leader/LeaderSelectorListenerAdapter.java <https://github.com/apache/curator/blob/master/curator-recipes/src/main/java/org/apache/curator/framework/recipes/leader/LeaderSelectorListenerAdapter.java>).
-Jordan > On Apr 3, 2019, at 7:17 PM, Xu Cang <[email protected]> wrote: > > Hi Zookeeper/ Curator users and developers, > I have a question regarding this method: isOwnedByCurrentThread() in > InterProcessSemaphoreMutex in Curator > > https://curator.apache.org/apidocs/org/apache/curator/framework/recipes/locks/InterProcessSemaphoreMutex.html#isAcquiredInThisProcess-- > > If scenario as below happens: > > 1. application using curator successfully acquired this mutex. > 2. application lost connection to Zookeeper for several mins and lost ZK > connection. > 3. After connection re-established, ZK state became RECONNECTED from LOST. > > At this point, can I directly call isOwnedByCurrentThread() to determine if > this process has ownership of this mutex? > If yes, who is updating the 'lease' variable > https://github.com/apache/curator/blob/master/curator-recipes/src/main/java/org/apache/curator/framework/recipes/locks/InterProcessSemaphoreMutex.java#L78 > > If no, what's the recommended way to determine if this process has the > mutex's ownership or not? > > Thank you in advance. > > Xu
