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 < [email protected]> wrote: > 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]> 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 >> >> > >
