You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@curator.apache.org by Stephan Ewen <se...@apache.org> on 2016/07/19 10:31:03 UTC
Attaching a Fencing Token to a Leader Latch
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
Re: Attaching a Fencing Token to a Leader Latch
Posted by Stephan Ewen <se...@apache.org>.
Actually, creating a new LeaderLatch every time works.
We have a bunch of leader observers that need to grab that ID (we use the
node cache for that) - we can just read the bytes from the znode and
reconstruct the ID there.
Thanks!
On Tue, Jul 19, 2016 at 2:21 PM, Jordan Zimmerman <
jordan@jordanzimmerman.com> wrote:
> 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 <se...@apache.org> 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 <
> 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 <se...@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
>>
>>
>>
>
>
Re: Attaching a Fencing Token to a Leader Latch
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
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 <se...@apache.org> 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 <jordan@jordanzimmerman.com <ma...@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 <ma...@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
>>
>
>
Re: Attaching a Fencing Token to a Leader Latch
Posted by Stephan Ewen <se...@apache.org>.
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 <se...@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
>
>
>
Re: Attaching a Fencing Token to a Leader Latch
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
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 <se...@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
>