Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 289A5200B43 for ; Tue, 19 Jul 2016 14:21:20 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 272AA160A76; Tue, 19 Jul 2016 12:21:20 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 4D9E3160A89 for ; Tue, 19 Jul 2016 14:21:19 +0200 (CEST) Received: (qmail 7575 invoked by uid 500); 19 Jul 2016 12:21:18 -0000 Mailing-List: contact user-help@curator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@curator.apache.org Delivered-To: mailing list user@curator.apache.org Received: (qmail 7565 invoked by uid 99); 19 Jul 2016 12:21:18 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 19 Jul 2016 12:21:18 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 1149ACFE40 for ; Tue, 19 Jul 2016 12:21:18 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.98 X-Spam-Level: * X-Spam-Status: No, score=1.98 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=jordanzimmerman-com.20150623.gappssmtp.com Received: from mx2-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id voolwToC0_cf for ; Tue, 19 Jul 2016 12:21:15 +0000 (UTC) Received: from mail-yw0-f176.google.com (mail-yw0-f176.google.com [209.85.161.176]) by mx2-lw-eu.apache.org (ASF Mail Server at mx2-lw-eu.apache.org) with ESMTPS id 726355FBE1 for ; Tue, 19 Jul 2016 12:21:15 +0000 (UTC) Received: by mail-yw0-f176.google.com with SMTP id r9so14249554ywg.0 for ; Tue, 19 Jul 2016 05:21:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jordanzimmerman-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:references:to:in-reply-to; bh=CgYrWk6SVsZneriS09OsNlCGjjlhoVzLxlcWWBEtk88=; b=foEyMl0vBKxx+kESrjzvXsBpwDVHxcReGyZXiezaDrMo9R8p/R5ZVTMxSeUhyMLpFO LG9xTSO/rHH3//X7onEf6C1mlFOmnE0MVCOV39Cuvp9PKzjhBp9asw2F4ayqImPsmjen hPikKPrQ1hF9FNXCzGleDr/ffPewmav7p3YA0suiRomgbT6cTJwA8Qb9FVBgWLdsv1pj uni7jXCHAyjUOA354i1PFzQ5K9sReUzQGXP9FywUNRcjTQQwDq2KAAtC3fN48UMHdeRU KK0J35x2ZAV6AkSvvcV60a2arNIq3auoqQVftsnrYe90UygCRxpEaqJP6V6T6xHCbnW7 I/KA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :references:to:in-reply-to; bh=CgYrWk6SVsZneriS09OsNlCGjjlhoVzLxlcWWBEtk88=; b=eyKvu3UwKplRR66xqCJuJIcsEAWikNjZGF7skUldGtmQAeS9znQ4mah9Ecr2tgvUZX fjpA7p7h3e35tgie0QWh+eVsFPjovTZgJJmXHzjjDavQ+ETKLY9iW8BTYdByw26p4ltZ lgvrYZ+hFsGkPVy16RwQJiVToVQ8TgZ8excNKAQAvjWIEammvhTc4b90s9sYbY2xDP3C nXxT3GAkLc+G7ZNM8WYGqQZ+oYU5in/AsxC7eoM63lJUnSq32pwUjX2L5y00CXVzjpuT CHuB+lcSVCLsn+gG+n8hOG+SIaHyyMP6dVnjjf0Nc9xJClHgX+xRh7o/oQcKoXm5WXs4 weWA== X-Gm-Message-State: ALyK8tJdFpGHmB1ZGgFDDFljgZWMcihfklw2mrTiKmsnfQr9UISg+G8dCEEeoQGd3ot37A== X-Received: by 10.129.110.137 with SMTP id j131mr21043694ywc.190.1468930874156; Tue, 19 Jul 2016 05:21:14 -0700 (PDT) Received: from [10.0.1.4] ([186.74.13.5]) by smtp.gmail.com with ESMTPSA id m189sm6211415ywf.39.2016.07.19.05.21.12 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 19 Jul 2016 05:21:12 -0700 (PDT) From: Jordan Zimmerman Content-Type: multipart/alternative; boundary="Apple-Mail=_0D30CDE1-A5D9-4F80-83C8-0E6498588DB1" Message-Id: <8BBB1050-63B3-426C-ABFE-3CC3ABB226E0@jordanzimmerman.com> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Attaching a Fencing Token to a Leader Latch Date: Tue, 19 Jul 2016 07:21:11 -0500 References: <7FD74A9F-9561-4736-8AD0-20F5481D9F0A@jordanzimmerman.com> To: user@curator.apache.org In-Reply-To: X-Mailer: Apple Mail (2.3124) archived-at: Tue, 19 Jul 2016 12:21:20 -0000 --Apple-Mail=_0D30CDE1-A5D9-4F80-83C8-0E6498588DB1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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 wrote: >=20 > Hi! >=20 > =46rom what I understood from the API docs, that id is the same every = time that specific contender becomes leader. >=20 > 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. >=20 > Stephan >=20 >=20 > On Tue, Jul 19, 2016 at 1:51 PM, Jordan Zimmerman = > wrote: > There=E2=80=99s a constructor in LeaderLatch that takes an =E2=80=9Cid=E2= =80=9D. That id is the payload for the lock node. >=20 > public LeaderLatch(CuratorFramework client, String latchPath, = String id) >=20 > You can call getParticipants() to get the IDs of all participants in = the latch. >=20 >> On Jul 19, 2016, at 5:31 AM, Stephan Ewen > wrote: >>=20 >> Hi Curators! >>=20 >> We are using the curator LeaderLatch recipe for leader election - so = far works great! >>=20 >> 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. >>=20 >> 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. >>=20 >> 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? >>=20 >> Greetings, >> Stephan >>=20 >=20 >=20 --Apple-Mail=_0D30CDE1-A5D9-4F80-83C8-0E6498588DB1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
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!

=46rom 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=E2=80=99s a constructor = in LeaderLatch that takes an =E2=80=9Cid=E2=80=9D. 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




= --Apple-Mail=_0D30CDE1-A5D9-4F80-83C8-0E6498588DB1--