curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jordan Zimmerman <jor...@jordanzimmerman.com>
Subject Re: About leader-latch usage and listener.close method.
Date Tue, 01 Apr 2014 15:32:06 GMT
The default version removes the listener so that there is no notification, which is the default
behavior.

-JZ


From: Osman osmanscam@gmail.com
Reply: Osman osmanscam@gmail.com
Date: April 1, 2014 at 10:29:18 AM
To: Jordan Zimmerman jordan@jordanzimmerman.com
Cc: user@curator.apache.org user@curator.apache.org
Subject:  Re: About leader-latch usage and listener.close method.  

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






--
Osman Sebati Çam

https://twitter.com/osmanscam




Mime
View raw message