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
