curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jordan Zimmerman <jor...@jordanzimmerman.com>
Subject Re: LeaderLatch implementation question
Date Mon, 14 Dec 2015 01:38:53 GMT
It’s OK with me but it will be tricky to write.

> On Dec 13, 2015, at 8:37 PM, Cameron McKenzie <mckenzie.cam@gmail.com> 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 <jordan@jordanzimmerman.com <mailto:jordan@jordanzimmerman.com>>
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 <cammckenzie@apache.org <mailto:cammckenzie@apache.org>>
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
> 
> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message