On Mon, Nov 14, 2011 at 1:28 AM, Jordan Zimmerman <[email protected]> wrote: > On 11/13/11 3:40 PM, "Jérémie BORDIER" <[email protected]> wrote: > >>As noticed in ZOOKEEPER-1209, this can cause really important issues. >>As Leader election is one of the most demanded feature / recipe, I >>would really like to see the official recipe fixed and fully >>functional. > > Curator handles this in its API. Our LeaderSelector takes a listener > instance that has two methods: > public void takeLeadership(CuratorFramework client) throws > Exception; > > public void notifyClientClosing(CuratorFramework client); > > The second method is the important one here. You can think of this like > the JDK's thread interruption mechanism. If a split brain occurs, the > leader connected to the bad half will have its notifyClientClosing method > called. > > > BTW - all of our recipes have this kind of mechanism. > > -JZ > >
Hello Jordan, Thanks a lot for your answer. I tried to figure out where the handling of Disconnected / Expired takes place, but so far I understood that to have notifyClientClosing() called from the Lock, an exception needs to be raised from somewhere. LockInternal may throw a ConnectionLossException if we don't find ourselves in the node members during the lock acquiring process, but I can't find where the exception comes from when the lock is already acquired (so outside of the acquiring loop). Could you point me to the right bits ? I believe what you're saying, just want to fully understand the different parts before starting using it ;) Thanks again ! Jérémie
