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
> 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'
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
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:
>
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.
>
In my case, it would be my client application - I
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
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?
>
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
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
>
>
> 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
Hi Folks,
I'm constructing an async api on top of the zookeeper python bindings for
twisted. The intent was to make a thin wrapper that would wrap the existing
async api with one that allows for integration with the twisted python event
loop (http://www.twistedmatrix.com) primarily using the async
12 matches
Mail list logo
