curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephan Ewen <>
Subject Re: Attaching a Fencing Token to a Leader Latch
Date Tue, 19 Jul 2016 12:17:19 GMT

>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.


On Tue, Jul 19, 2016 at 1:51 PM, Jordan Zimmerman <> 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 <> 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

View raw message