> 4) This was brought up on the list recently: is there a strategy for
> managing the ensemble member replacment problem? It's pretty
> undesirable to restart clients to learn about a replaced machine.
We've implemented a patch on the C client that allows for modifying
the server list at runtime without restarting the client.
That only solves part of the problem - for tracking the actual server
list, we maintain the list in ZK itself, and clients watch the list
for changes then reconfigure themselves. That part is implemented in
our app code, not the ZK client. When they initially connect, the use
the cached list of servers from the last time they connected and we
have a discovery mechanism for clients who have never connected.
If there's interest in the modified C client we're happy to submit a
patch. A similar modification to the Java client would not be hard.