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 20:50:14 GMT
Yep, that was the plan.

I'll have a look into it when I get a bit of spare time. I'm probably not
going to get much time until the new year, but we'll see how we go.
cheers


On Mon, Dec 14, 2015 at 11:54 PM, Jordan Zimmerman <
jordan@jordanzimmerman.com> wrote:

> 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> 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