Hi! >From what I understood from the API docs, that id is the same every time that specific contender becomes leader.
What I am looking for is a unique value for every time leader status changes (which is when a different znode gets created). We need that to separate actions taken by a participant across being leader, losing leadership, and re-gaining its leadership. Stephan On Tue, Jul 19, 2016 at 1:51 PM, Jordan Zimmerman < [email protected]> wrote: > There’s a constructor in LeaderLatch that takes an “id”. That id is the > payload for the lock node. > > public LeaderLatch(CuratorFramework client, String latchPath, String id) > > You can call getParticipants() to get the IDs of all participants in the > latch. > > On Jul 19, 2016, at 5:31 AM, Stephan Ewen <[email protected]> wrote: > > Hi Curators! > > We are using the curator LeaderLatch recipe for leader election - so far > works great! > > We need to additionally attach a "fencing token" to the leader latch - > basically a random unique ID that can be used to identify actions taken > under the assumption of a certain node holding the leader latch. This token > should be retrieved atomically with the leader status and live and die with > the leader status. > > Its seems natural to use the leader latch znode for that. > We were thinking to either use the latch's znode zxid, or to write some > bytes to the znode (or attach a child node) to it. > > The recipe does not provide any access to the znode, however. What would > you recommend to do here? Is it possible to add (read only) access to the > znode in the LeaderLatch? > > Greetings, > Stephan > > >
