curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cameron McKenzie <mckenzie....@gmail.com>
Subject Re: LeaderLatch implementation question
Date Mon, 14 Dec 2015 02:10:23 GMT
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> 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>
> 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> 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>
>> 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