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

John Vines commented on CURATOR-171:
------------------------------------

So, my case is in the event of a network partition occuring. If 2 nodes (or N + 
1) nodes are in a cluster, and one of them happens to be the leader, but they 
get partitioned from one each other but maintain access to ZK, then the leader 
will keep being the leader even though it can't communicate with the rest of 
the cluster. In this event I would have a process rip out the leader's lock to
1. Get a new leader elected that can talk to the cluster
and 2. Ideally this would be extensible such that I can tell the partitioned 
server to die since it's not part of the cluster

> 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)

Reply via email to