curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephan Ewen <se...@apache.org>
Subject Re: Attaching a Fencing Token to a Leader Latch
Date Tue, 19 Jul 2016 12:17:19 GMT
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 <
jordan@jordanzimmerman.com> 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 <sewen@apache.org> 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
>
>
>

Mime
View raw message