curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jordan Zimmerman <jor...@jordanzimmerman.com>
Subject Re: Error handling for CuratorFramework and LeaderLatch
Date Wed, 17 Jul 2013 23:30:54 GMT
Consider using LeaderSelector instead: http://curator.incubator.apache.org/curator-recipes/leader-election.html
- in this recipe it's up to you to release leadership (even in the face of connection issues).

-Jordan

On Jul 17, 2013, at 4:21 PM, chao chu <chuchao333@gmail.com> wrote:

> Hi,
> 
> In our application, we are using the LeaderLatch for leader election, however, we don't
want our app rely on the zk's availibility. That is to say, when zk become unavailable, it
shouldn't affect our application, the last known leader should be still the leader during
zk's absent and other participants still serve as the followers.
> 
> However, in LeaderLatch, it sets the leadership to false as long as the connection is
SUSPEND or LOST. It seems that I had to maintain a local 'leadership' flag and my 'isLeading'
query should be sth like:
> 
>  latch.hasLeadership || (!latch.hasLeadership && disconnected && previousIsLeader)
> 
> Does it make sense?
> 
> And also, we need to catch any possible exceptions thrown in curator. My question is
that, except those exceptions on zk operations failures (after all the retries), the only
possible one seems to me is just the ConnectionLossException when curator couldn't connect
to zk within the 'connectionTimeout' in any case?
> 
> Thanks & Regards,
> 
> -- 
> ChuChao


Mime
View raw message