Yep, that was the plan. I'll have a look into it when I get a bit of spare time. I'm probably not going to get much time until the new year, but we'll see how we go. cheers
On Mon, Dec 14, 2015 at 11:54 PM, Jordan Zimmerman < [email protected]> wrote: > 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]> 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 >>> >>> >> >> > >
