curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jordan Zimmerman <>
Subject Re: Question about handling SUSPEND state from ConnectionStateListener
Date Fri, 14 Nov 2014 12:40:32 GMT
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. 


On November 14, 2014 at 5:17:10 AM, Jipeng Tan ( 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
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?


View raw message