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 <[email protected]> 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
