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 01:37:47 GMT
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