hadoop-zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Hunt <ph...@apache.org>
Subject Re: Dynamic adding/removing ZK servers on client
Date Mon, 03 May 2010 18:03:19 GMT

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.


View raw message