curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ioannis Canellos <>
Subject Re: Ensemble Provider best practices
Date Mon, 29 Apr 2013 15:50:45 GMT
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 <> 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 <> 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*

Twitter: iocanel

View raw message