The conservative thing to do is to assume that the connection is lost and release the lock. The recipes in Curator usually treat SUSPENDED the same as LOST. However, you can take a more lenient stance and assume you still have the lock until LOST is received.
-Jordan On November 14, 2014 at 5:17:10 AM, Jipeng Tan ([email protected]) wrote: Hi All, I want to ask a question about handling SUSPEND state. Here is the background: I am using curator/zk to as a task coordinator for a list of concurrent running jobs. For every minute, every worker (each work run on a separate VM) try to acquire a task (lock) from zk by calling: lock = new InterProcessSemaphoreMutex(zkClient, task); boolean hasLock = false; hasLock = lock.acquire(1, TimeUnit.SECONDS); If the work get the lock, it will do the task. The class which is responsible for retriever lock/task implement ConnectionStateListener interface. And below is the currently implementation: RECONNECT: do nothing, since worker will try to acquire lock regardless the ZK connection status. LOST: release the lock, since the connect is lost. SUSPEND: ?????? My question is about SUSPEND state, should I release the lock when enter SUSPEND (basically, treat as lost) or do something else? What is the best practice to handle SUSPEND state? Thanks, Jipeng
