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