In the past, LeaderLatch did _not_ notify when closed. A recent update (2.4.0 I think) added a CloseMode to LeaderLatch so that you can have it notify on close. Try that.
I wonder what can be the side affect if JVM containing the listeners crashed and application may not call this close method? Obviously everything on the Application/Client side will gone but Regarding the listeners, Is there anything stored/marked on the zookeeper side? Which part of the code I should check to understand in detail How these listeners work and interact with Zookeeper? LeaderLatch uses ephemeral znodes. If your JVM crashes, ZooKeeper will delete the latch’s znode when the session times out. -JZ From: Osman [email protected] Reply: [email protected] [email protected] Date: April 1, 2014 at 3:26:34 AM To: [email protected] [email protected] Subject: About leader-latch usage and listener.close method. Hello; using curator 2.3.0 (recipes & framework & client) I am trying leader-latch, and for that I wrote a simple test case attached which is running successfully for the scenario below. creates a LeaderLatchListener A A attempts to acquire leadership and gets it creates an another LeaderLatchListener B B attempts to acquire leadership and not gets it A stops the latch and B gets the leadership. However, I cannot managed to get triggered when the leadership lost. I can understand that leadership is gone by calling the hasLeadership method but Listener is not get triggered. (Leader that is gaining the leadership is get triggered, but Leader loosing the leadership is not get triggered.) When I look at the LeaderLatch.close call I see that first listeners removed and then leadership set to false. finally { client.getConnectionStateListenable().removeListener(listener); listeners.clear(); setLeadership(false); } and on setLeadership(false) there is the notLeader call. @Override public Void apply(LeaderLatchListener listener) { listener.notLeader(); return null; } Do you think if it is better if we have this finally block in this sequence? finally { setLeadership(false); client.getConnectionStateListenable().removeListener(listener); listeners.clear(); } another question is, Apart from the leader-latch, I am using path-cache and node-cache and each of these 3 should be closed with close() call. (Closeable) For Leader Latch, there is a comment on the code "IMPORTANT: the only way to release leadership is by calling close(). All LeaderLatch instances must eventually be closed." And in the implementation of the close code, Curator removes the listeners registered. and For leaderLatch extra it calls setNode(null); I wonder what can be the side affect if JVM containing the listeners crashed and application may not call this close method? Obviously everything on the Application/Client side will gone but Regarding the listeners, Is there anything stored/marked on the zookeeper side? Which part of the code I should check to understand in detail How these listeners work and interact with Zookeeper? For example: if I remove the anotherleadershipListener.stop(); from the test case attached, for a single iteration of the test case still runs successfully but what can be the invisible affect here? Thank You, Regards. -- Osman Sebati Çam https://twitter.com/osmanscam
