curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jordan Zimmerman <jor...@jordanzimmerman.com>
Subject Re: Leader latch
Date Mon, 21 Oct 2013 13:14:02 GMT
LeaderLatch has a close() method. It's the user's responsibility to close the latch when done
with it. So, close any latches (or any other close-able object) before closing the Curator
instance.

-Jordan

On Oct 20, 2013, at 10:53 PM, Cameron McKenzie <mckenzie.cam@gmail.com> wrote:

> With a LeaderLatch, if the underlying CuratorFramework instance gets closed (i.e. has
close() called on it), what is meant to happen? I would have expected the latch to be discarded.
Currently it just seems to retain whatever state it was in prior to the framework being closed.
i.e If the leader calls await() it returns. If hasLeadership() gets called, it returns true.
> 
> I believe the root of this problem is that the LeaderLatch implementation is looking
for connection state changes (SUSPENDED, LOST etc.) and basing its state on these. When close()
gets called on the CuratorFramework though, no such event is generated.
> 
> So, should LeaderLatch be modified to implement CuratorListener as well and look for
CLOSING events? Or should close() on CuratorFramework generate a LOST connection event? Or
is my use case just bogus?
> 
> Essentially, what I'm trying to achieve is to be able to reconfigure the connection to
the ZooKeeper ensemble dynamically (i.e. without a system restart), and based on the current
Curator / ZooKeeper implementation, this requires recreating the CuratorFramework instance,
because there''s no way to set timeouts etc. on a current CuratorFramework instance. It's
possible via implementing an EnsembleProvider to provide restricted reconfiguration for connection
strings.
> cheers


Mime
View raw message