After digging more into the problem, I see that the ConnectionStateManager will propagate the LOST event into the ZooKeeperClient but I fail to see how it could work the other way around.
Also for that particular use case, I can't restart the framework as it would wipe the listeners. What I tried locally and did work for me, was to add a reset() method in the CuratorFramework that stops/starts the client without restarting the connection manager (preserving this way the listeners) and propagates manually a LOST event. However, I am not sure if this could be a generally accepted solution or just a workaround the problem. On Mon, Apr 29, 2013 at 6:36 PM, Jordan Zimmerman < [email protected]> wrote: > There is a bug either in Curator or ZooKeeper (I believe it's ZK) that > causes the connection to hang and never reset. I'm working on a solution > (it will be in the Apache version of Curator). So, yes, use > EnsembleProvider. > > On Apr 26, 2013, at 12:24 PM, Ioannis Canellos <[email protected]> wrote: > > > Hi, > > > > I have a case where the ensemble can change (by adding/removing zk > servers) and I wanted to find the best approach on reconfiguring the > curator framework. > > It seemed like a good idea to implement my custom ensemble provider, > which would receive updates with the modified connectionString. > > > > This works fine, if I mark the zookeeper client as lost (so that the > framework can pick the updated connection string from the EnsembleProvider). > > The problem is that after that the ConnectionStateListeners are not > receiving any events for CONNECTED/RECONNECTED etc. > > > > Is this expected? > > > > Is there any other approach for changing the connection string, without > recreating the CuratorFramework? > > > > Thanks in advance. > > > > -- *Ioannis Canellos* * ** Blog: http://iocanel.blogspot.com ** Twitter: iocanel *
