Thanks. Considering that methods method1 and method2 are really fast methods and are not really cancelable I think the AtomicReference should work the best.
- Drew On Mar 14, 2014, at 7:30 AM, Jordan Zimmerman <[email protected]> wrote: > A few things: > > * It’s overkill to use a read/write lock to store the connection state. Just > use an AtomicReference > > * You’re using InterProcesMutex correctly from what I can see. > > * While running method1()/method2() etc. periodically check the connect > state. If it’s not CONNECTED or RECONNECTED exit whatever you’re doing and > try to acquire the lock again. Alternatively, CuratorManager can keep track > of threads that are using Curator objects and interrupt them when there is a > connection problem. > > -JZ > > > From: Drew Kutcharian [email protected] > Reply: [email protected] [email protected] > Date: March 13, 2014 at 6:33:06 PM > To: [email protected] [email protected] > Subject: Correct way to use InterProcessMutex and ConnectionStateListener > >> Hi Guys, >> >> I’m pretty new to Curator and I’m still trying to figure out how to use >> ConnectionStateListener. Mainly, how can I combine an InterProcessMutex and >> a ConnectionStateListener. As an example, what’s the correct way to user an >> InterProcessMutex and ConnectionStateListener in the following use case: >> >> https://gist.github.com/kutchar/9539322 >> >> Thanks, >> >> Drew
