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:40:28 GMT
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 <sewen@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 <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