curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Osman <osmans...@gmail.com>
Subject About leader-latch usage and listener.close method.
Date Tue, 01 Apr 2014 08:25:57 GMT
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>

Mime
View raw message