curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jordan Zimmerman <jor...@jordanzimmerman.com>
Subject Re: LeaderLatch implementation question
Date Mon, 14 Dec 2015 12:54:15 GMT
It would be nice if you used 3.0’s ConnectionStateErrorPolicy to control this.

-JZ

> On Dec 13, 2015, at 9:10 PM, Cameron McKenzie <mckenzie.cam@gmail.com> wrote:
> 
> Maybe I haven't dug deep enough into it, but shouldn't it just be a matter of handling
the RECONNECT event and checking if the latches current zNode exists and is bound to the current
session?
> 
> If it is, then just rerun the election logic.
> If it doesn't exist then recreate it (ephemeral sequential).
> If it exists and is bound to another session (this shouldn't happen), then just recreate
a new leader node.
> 
> This logic would be used in conjunction with the new definition of 'LOST' so that the
listeners of the latch would only be notified of a 'notLeader' event when a 'LOST' event is
generated (rather than on 'SUSPENDED' as is the current implementation).
> cheers
> 
> 
> 
> On Mon, Dec 14, 2015 at 12:38 PM, Jordan Zimmerman <jordan@jordanzimmerman.com <mailto:jordan@jordanzimmerman.com>>
wrote:
> It’s OK with me but it will be tricky to write.
> 
>> On Dec 13, 2015, at 8:37 PM, Cameron McKenzie <mckenzie.cam@gmail.com <mailto:mckenzie.cam@gmail.com>>
wrote:
>> 
>> I thought that the original reasoning may have been lost in the depths of time. 
>> 
>> Would you (or anyone else) have any objections to me knocking together a patch that
would (maybe optionally?) check for existing state to save unnecessary leadership changes?
>> 
>> On Mon, Dec 14, 2015 at 12:35 PM, Jordan Zimmerman <jordan@jordanzimmerman.com
<mailto:jordan@jordanzimmerman.com>> wrote:
>> I never trusted the messages I got from ZooKeeper and always tried to be as conservative
as possible. Other than that, I don’t remember :)
>> 
>> -Jordan
>> 
>> > On Dec 13, 2015, at 8:33 PM, Cameron McKenzie <cammckenzie@apache.org <mailto:cammckenzie@apache.org>>
wrote:
>> >
>> > Guys,
>> > I was looking at the LeaderLatch implementation while trying to track down
>> > some production issues, and I was wondering why the leader election zNode
>> > is recreated each time a RECONNECTED event occurs (and the existing one is
>> > deleted). Wouldn't it be more efficient to check if the current value in
>> > the 'ourPath' reference exists (and is owned by our session) first?
>> >
>> > With the current implementation, it's quite likely that a leadership change
>> > will occur every time a connection is lost, even if it reconnects before
>> > the session is lost. This seems sub optimal, as the change of leader may be
>> > an expensive process.
>> >
>> > Maybe I'm missing something?
>> > cheers
>> > Cam
>> 
>> 
> 
> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message