[
https://issues.apache.org/jira/browse/CURATOR-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15823814#comment-15823814
]
Parminder Grewal commented on CURATOR-171:
------------------------------------------
[~randgalt] While i understand that there is an overhead associated in creating
a watch for the nodes, I am making the assumption that the follower nodes (i.e.
nodes that aren't leaders) are already either periodically checking for the
existence of the ephemeral node or have a watch on it. That is how , even when
we delete the node, another follower assumes the role of the leader. (please
correct me if I am wrong).
Given the nature of leader election (number of followers > number of leaders),
i would assume that the load added by the leader watching its own ephemeral
node as well would be minimal. This would make this algorithm less susceptible
to issues like this.
To address the concern of performance, we could make the behavior configurable.
i.e. by default leader does not watch its own ephemeral node, but users can set
a flag to do so.
Also it would be good to highlight this in user docs? (maybe it already is
somewhere)
> 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)
