curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cameron McKenzie <>
Subject Re: ZooKeeper 3.5.0 is coming
Date Thu, 07 Aug 2014 05:44:54 GMT
>From the following:

It appears that from Curator's point of view, we need to be aware of config
changes (by watching the /zookeeper/config zNode), to determine when the
clusters configuration has changed. Then, if it has changed, determine
whether our client needs to connect to a different host in the cluster.
There are underlying API calls on the Zookeeper client that handle the
algorithms for reconnection, Curator would just need to identify when the
changes occur.

Presumably we'd add something to the CuratorFramework and
CuratorFrameworkFactory classes.

This sort of changes the way that client configuration works to a degree.
Instead of it being a static thing where you configure your list of ZK
nodes, and that's it, now you're kind of configuring a set (potentially a
subset of all ZK nodes in the cluster) of ZK nodes that will then allow you
to look up the full set of nodes in the cluster. I would think that this
needs to be optional, but I think that it would be useful functionality to
have Curator be able to configure itself against what the ZK cluster
considers the cluster members to be at startup, and then dynamically
reconfigure itself as this changes.

So, essentially, Curator would:
-Connect to one of its configured ZK nodes
-Read the /zookeeper/config configuration
-Reconfigure itself based on that configuration
-Watch for future config updates.

I'm happy to start looking into this in a bit more detail unless someone
else has their heart set on it.

On Wed, Aug 6, 2014 at 10:53 PM, Jordan Zimmerman <> wrote:

> An alpha of ZooKeeper 3.5.0 is being released. We should start thinking
> about how Curator should adjust to 3.5.x features, in particular
> (dynamic reconfig).
> -Jordan

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message