Manual removal of the latch node isn’t supported. It would require the latch to add a watch on its own node and that has performance/runtime overhead. The recommended behavior is to watch for connection loss/suspended events and exit your latch when that happens.
-Jordan > On Aug 17, 2016, at 12:43 PM, Steve Boyle <[email protected]> wrote: > > I’m using the Leader Latch recipe. I can successfully bring up two instances > of my app and have one become ‘active’ and one become ‘standby’. Most > everything works as expected. We had an issue, in production, when adding a > zookeeper to our existing quorum, both instances of the app became ‘active’. > Unfortunately, the log files rolled over before we could check for > exceptions. I’ve been trying to reproduce this issue in a test environment. > In my test environment, I have two instances of my app configured to use a > single zookeeper – this zookeeper is part of a 5 node quorum and is not > currently the leader. I can trigger both instances of the app to become > ‘active’ if I use zkCli and manually delete the latch path from the single > zookeeper to which my apps are connected. When I manually delete the latch > path, I can see via debug logging that the instance that was previously > ‘standby’ gets a notification from zookeeper “Got WatchedEvent > state:SyncConnected type:NodeDeleted”. However, the instance that had > already been active gets no notification at all. Is it expected that > manually removing the latch path would only generate notifications to some > instances of my app? > > Thanks, > Steve Boyle
