You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@curator.apache.org by chao chu <ch...@gmail.com> on 2013/07/18 01:21:31 UTC
Error handling for CuratorFramework and LeaderLatch
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
Re: Error handling for CuratorFramework and LeaderLatch
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
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 <ch...@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 <jo...@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 <ch...@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
Re: Error handling for CuratorFramework and LeaderLatch
Posted by chao chu <ch...@gmail.com>.
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 <ch...@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
Re: Error handling for CuratorFramework and LeaderLatch
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
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 <ch...@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