Mailing-List: contact dev-help@curator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@curator.apache.org
Date: Mon, 16 Jan 2017 20:23:26 +0000 (UTC)
From: "Scott Blum (JIRA)" <jira@apache.org>
To: dev@curator.apache.org
Message-ID: <JIRA.12760559.1418160605000.19074.1484598206814@Atlassian.JIRA>
In-Reply-To: <JIRA.12760559.1418160605000@Atlassian.JIRA>
References: <JIRA.12760559.1418160605000@Atlassian.JIRA> <JIRA.12760559.1418160605394@jira-lw-us.apache.org>
Subject: [jira] [Commented] (CURATOR-171) LeaderLatch isn't aware if it's
 own ephemeral node goes away
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Mon, 16 Jan 2017 20:23:35 -0000


    [ https://issues.apache.org/jira/browse/CURATOR-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15824551#comment-15824551 ] 

Scott Blum commented on CURATOR-171:
------------------------------------

I could totally get on board with the idea that everyone watches exactly one node, and the leader watches himself.  It's one extra watch, not per node, but per election.  Seems a small price to pay if it allows you to externally nuke the election and retry to fix a borked state.

> LeaderLatch isn't aware if it's own ephemeral node goes away
> ------------------------------------------------------------
>
>                 Key: CURATOR-171
>                 URL: https://issues.apache.org/jira/browse/CURATOR-171
>             Project: Apache Curator
>          Issue Type: Bug
>          Components: Recipes
>            Reporter: John Vines
>
> Running the following code- {code}  public static void main(String args[]) throws Exception {
>     CuratorFramework curator = CuratorFrameworkFactory.builder().connectString("localhost:2181").retryPolicy(new ExponentialBackoffRetry(1000, 5))
>         .authorization("digest", "accumulo:DEFAULT".getBytes()).build();
>     curator.start();
>     LeaderLatch latch = new LeaderLatch(curator, "/latch", "test");
>     LeaderLatch latch2 = new LeaderLatch(curator, "/latch", "test2");
>     latch.addListener(new LeaderLatchListener() {
>       @Override
>       public void isLeader() {
>         System.out.println("Became leader!");
>       }
>       @Override
>       public void notLeader() {
>         System.out.println("Lost leadership!");
>       }
>     });
>     latch.start();
>     latch.await();
>     latch2.start();
>     Thread.sleep(1000);
>     System.out.println("Does latch1 have leadership? " + latch.hasLeadership());
>     System.out.println("Does latch2 have leadership? " + latch2.hasLeadership());
>     for (String child : curator.getChildren().forPath("/latch"))
>       if (Arrays.equals(curator.getData().forPath(ZKPaths.makePath("/latch", child)), "test".getBytes()))
>           curator.delete().deletingChildrenIfNeeded().forPath(ZKPaths.makePath("/latch", child));
>     Thread.sleep(1000);
>     System.out.println("Does latch1 have leadership? " + latch.hasLeadership());
>     System.out.println("Does latch2 have leadership? " + latch2.hasLeadership());
>     
>     Thread.sleep(1000 * 40);
>     System.out.println("Does latch1 have leadership? " + latch.hasLeadership());
>     System.out.println("Does latch2 have leadership? " + latch2.hasLeadership());
>     
>     latch.close();
>     latch2.close();
>     curator.close();
>   }{code}
> I get the following output-{noformat}Became leader!
> Does latch1 have leadership? true
> Does latch2 have leadership? false
> Does latch1 have leadership? true
> Does latch2 have leadership? true
> Does latch1 have leadership? true
> Does latch2 have leadership? true
> {noformat}
> I expect that when the ephemeral node is deleted, latch1 no longer reports itself as having leadership. Furthermore, I expect it to trigger the notLeader call.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)