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 <[email protected]> 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
