It’s OK with me but it will be tricky to write.
> On Dec 13, 2015, at 8:37 PM, Cameron McKenzie <[email protected]> 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
> <[email protected] <mailto:[email protected]>> 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 <[email protected]
> > <mailto:[email protected]>> 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
>
>
