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 Thu, 18 Jul 2013 00:02:11 GMT
The management of the ZooKeeper instance is done in the curator-client module via classes such
as ConnectionState.java (there are two classes with this name unfortunately).

-Jordan

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

> Hi Jordan,
> 
> Thanks for your quick response. I will give it a try. Previously, when I checked the
recipes, just thought the LeaderLatch is easier to use :)
> 
> btw, by reading the code in CuratorFrameworkImpl, it's not very clear to me on how itself
handle connection state changes, it holds 'ConnectionStateManager', but seems that it's just
add state changes on it for the listeners. How about if there are no other listeners at all?
I must miss something, which part in CuratorFrameworkImpl itself handles the connection state
changes? Or it simply doesn't care? since in 'ConnectionState' instance, it will make sure
to get a valid zk handle each time as long as zk is available?
> 
> 
> On Thu, Jul 18, 2013 at 7:30 AM, Jordan Zimmerman <jordan@jordanzimmerman.com>
wrote:
> 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
> 
> 
> 
> 
> -- 
> ChuChao


Mime
View raw message