On 05/03/2010 10:28 AM, Dave Wright wrote:
You might also look at this patch, we never committed it but it might be
interesting to you:
https://issues.apache.org/jira/browse/ZOOKEEPER-146

The benefit is that you'd only have one place to make the change, esp given
that clients might be down/unreachable when this change occurs. Clients
would have to poll this service whenever they get disconnected from the
ensemble. One drawback of this approach is that the HTTP now becomes a
potential SPOF. (although I guess you could always fall back to something,
or potentially have a list of HTTP hosts to do the lookup, etc...).

Well, that just handles distribution of the list (which isn't really
our problem), it doesn't help with restarting the ZK client when the
list changes - it only pulls the list once, so you still have to
completely shutdown and restart the ZK client.


Well the old server is being shutdown right? If the client were connected to that server this would force the client to reconnect to another server, what I was suggesting is that the client would ping the "server lookup" service as part of this. (so lookup on every disconnect say)


It does sound interesting, however once we add something like this it's hard
to change given that we try very hard to maintain b/w compatibility. If you
did the testing and were able to verify I don't see why we couldn't add it -
as it's "optional" in the sense that it would only be called in the use case
you describe. I would feel more confident if we had more concrete detail on
how we intend to do 107 (a basic functional/design doc that at least reviews
all the issues), and how this would fit in. But I don't see that should
necessarily be a blocker (although others might feel differently).

Have you ever considered adding features like this via a protected
interface (i.e. the are useful but aren't fully standardized, so if a
client wants to use it they can sub-class ZK and make them public)?


If you take a look at the end of ZooKeeper you'll see that we have some like that already, but IIRC they were for testing purposes. But yes, that would be a great way to expose it. We could also mark the initial version as "experimental" or perhaps "unstable" letting potential users know that we're still working on it.

The ability to dynamically modify the server list on the client side
seems like it would be required no matter what approach were taken to
dynamic clusters.

Hasn't come up before, but yes I agree it's a useful feature.

Patrick

Reply via email to