curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cameron McKenzie <>
Subject Leader latch
Date Mon, 21 Oct 2013 05:53:50 GMT
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

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.

View raw message