Why not just create a new LeaderLatch each time? Other than that, a PR with a settable id would be nice.
-Jordan > On Jul 19, 2016, at 7:17 AM, Stephan Ewen <[email protected]> wrote: > > 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] > <mailto:[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] >> <mailto:[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 >> > >
