TBH - I don't know why we never created a utility to automate this. We should add a "LockConnectionStateListener" or something that listens for connection state changes and tries to interrupt the locked thread when there's an issue. Until we have that though, you'd have to do this manually. We have "LeaderSelectorListenerAdapter" for LeaderSelector. You can look at that as an example of how to handle things.
-Jordan > On Jun 21, 2018, at 9:32 AM, Jakub Ječmínek <jecmi...@gmail.com> wrote: > > Hello, > I am using curator's InterProcessMutexes and I have found in the > documentation this note on error handling: > It is strongly recommended that you add a ConnectionStateListener and watch > for SUSPENDED and LOST state changes. If a SUSPENDED state is reported you > cannot be certain that you still hold the lock unless you subsequently > receive a RECONNECTED state. If a LOST state is reported it is certain that > you no longer hold the lock. > > Is there some best practice how to handle this? I have not found any official > example of handling the interprocessmutex, when connection to zookeeper is > lost. > > I guess I would have to have a separate boolean (probably > AtomicReference<Boolean>) that would indicate if connection to zookeeper is > present, because when connection is lost the isOwnedByCurrentThread and > isAcquiredInThisProcess methods still returns true. > This boolean reference would set in stateChanged method. Is this assumption > correct? > > I would be very grateful for any hints and help. > with best regards > Jakub Jecminek >
