>
>
> This is tricky: what happens if the server your client is connected to is
> decommissioned by a view change, and you are unable to locate another server
> to connect to because other view changes committed while you are
> reconnecting have removed all the servers you knew about. We'd need to
On 3 May 2010 16:40, Dave Wright wrote:
> > Should this be a znode in the privileged namespace?
> >
>
> I think having a znode for the current cluster members is part of the
> ZOOKEEPER-107 proposal, with the idea being that you could get/set the
> membership just by writing to that node. On the
> Should this be a znode in the privileged namespace?
>
I think having a znode for the current cluster members is part of the
ZOOKEEPER-107 proposal, with the idea being that you could get/set the
membership just by writing to that node. On the client side, you could
watch that znode and update yo
Yeah, that was one of the ideas, I think its been on the jira somewhere ( I
forget)... But could be and would definitely be one soln for it.
Thanks
mahadev
On 5/3/10 2:12 PM, "Ted Dunning" wrote:
> Should this be a znode in the privileged namespace?
>
> On Mon, May 3, 2010 at 1:45 PM, Dave Wr
Should this be a znode in the privileged namespace?
On Mon, May 3, 2010 at 1:45 PM, Dave Wright wrote:
> > Hi Dave,
> > Just a question on how do you see it being used, meaning who would call
> > addserver and removeserver? It does seem useful to be able to do this.
> This
> > is definitely wor
> Hi Dave,
> Just a question on how do you see it being used, meaning who would call
> addserver and removeserver? It does seem useful to be able to do this. This
> is definitely worth working on. You can link it as a subtask of
> ZOOKEEPER-107.
>
In my case, it would be my client application - I
Another benefit of ZOOKEEPER-146 - we could use this for some sort of
load balancing amongst the ensemble members. The first version could
return a static list, however I can see where the HTTPD might be updated
to monitor the load on the servers/ensemble and prioritize the list for
each client
Hi Dave,
Just a question on how do you see it being used, meaning who would call
addserver and removeserver? It does seem useful to be able to do this. This
is definitely worth working on. You can link it as a subtask of
ZOOKEEPER-107.
Thanks
mahadev
On 5/3/10 7:03 AM, "Dave Wright" wrote:
>
On 05/03/2010 07:03 AM, Dave Wright wrote:
I've got a situation where I essentially need dynamic cluster
membership, which has been talked about in ZOOKEEPER-107 but doesn't
look like it's going to happen any time soon.
Could you provide some insight into why you need this? Just so we have
a
> I've got a situation where I essentially need dynamic cluster
> membership, which has been talked about in ZOOKEEPER-107 but doesn't
> look like it's going to happen any time soon.
Wow, perfect timing! Vishal K just commented in the ticket moments
ago that he's interested in writing it. :-)
I'
I've got a situation where I essentially need dynamic cluster
membership, which has been talked about in ZOOKEEPER-107 but doesn't
look like it's going to happen any time soon.
For now, I'm planning on working around this by having a simple
coordinator service on the server nodes that will re-writ
11 matches
Mail list logo
