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