curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Osman <osmans...@gmail.com>
Subject Re: About leader-latch usage and listener.close method.
Date Tue, 01 Apr 2014 15:29:17 GMT
Yes, Thanks for the reply. using 2.4.1 fixes this with
latch.close(CloseMode.NOTIFY_LEADER); In that version first listener
updated and then removed.
I am wondering why the default version is removing the listeners first? or
why that default version is needed?

Regards.


On 1 April 2014 16:04, Jordan Zimmerman <jordan@jordanzimmerman.com> wrote:

> 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 osmanscam@gmail.com
> Reply: user@curator.apache.org user@curator.apache.org
> Date: April 1, 2014 at 3:26:34 AM
> To: user@curator.apache.org user@curator.apache.org
> Subject:  About leader-latch usage and listener.close method.
>
>  Hello;
>
> using curator 2.3.0 (recipes & framework & client)
>
> I am trying leader-latch<http://curator.apache.org/curator-recipes/leader-latch.html>,
> 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<http://curator.apache.org/curator-recipes/leader-latch.html>,
> I am using path-cache<http://curator.apache.org/curator-recipes/path-cache.html>
>  and node-cache<http://curator.apache.org/curator-recipes/node-cache.html> 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 <https://twitter.com/#!/osmanscam>
>
>
>
>    ------------------------------
>
>


-- 
Osman Sebati Çam

https://twitter.com/osmanscam <https://twitter.com/#!/osmanscam>

Mime
View raw message