[
https://issues.apache.org/jira/browse/ZOOKEEPER-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12863359#action_12863359
]
Vishal K commented on ZOOKEEPER-107:
Hi Henry,
We are using ZK for one the projects
Hi Henry,
I just commented on the Jira. I would be happy to contribute.
Please advise on the current status and next steps. Thanks.
Regards,
-Vishal
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
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 Vishal -
Great that you're interested in contributing! This would be a really neat
feature to get into ZK.
The documentation that exists is essentially all on the JIRA. I had a patch
that 'worked' but was nowhere near commit-ready. I'm trying to dig it up,
but it appears it may have gone to th
Hi Henry,
Thanks for the info. I will spend some more time to understand the issues
before starting with the implementation. I will let you know if I have any
questions (which I am sure I will).
Just to clarify, "by solved issue" you mean from design perspective and not
from implementation right?
Hi Vishal -
That's right - design, not implementation!
I'd encourage you to share a design document once you feel you understand
exactly what's required. This is probably going to be complex patch and
reviewers will need a study guide :)
cheers,
Henry
On 3 May 2010 10:26, Vishal Kher wrote:
>
> Could you provide some insight into why you need this? Just so we have addl
> background, I'm interested to know the use case.
Sure, we're building a clustered application that will use zookeeper
as part of it. We need to manage ZK ourself. The cluster running the
app & ZK may change over time (
Hi Vishal,
Just read through the jira that you guys are using ZooKeeper at Vmware.
Would you guys mind updating
http://wiki.apache.org/hadoop/ZooKeeper/PoweredBy
with how you folks are using ZooKeeper?
Thanks
mahadev
On 5/3/10 7:25 AM, "Vishal K" wrote:
> Hi Henry,
>
> I just commented on
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/unre
Hi Mahadev,
I will be happy to update it once we officially release our product.
On Mon, May 3, 2010 at 1:57 PM, Mahadev Konar wrote:
> Hi Vishal,
> Just read through the jira that you guys are using ZooKeeper at Vmware.
> Would you guys mind updating
>
> http://wiki.apache.org/hadoop/ZooKeepe
>> 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.
I agree with Dave that this is quite important for a truly dynamic
>> 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 s
On 05/03/2010 11:29 AM, Dave Wright wrote:
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.
On 05/03/2010 12:07 PM, Dave Wright wrote:
Yes, that's what I meant - we could update the ZK client lib to do this. It
would be invisible to the client application (your code) itself.
I don't think that's a bad idea, and the general approach in ZK-146 of
using an interface that gets called t
>
> Yes, that's what I meant - we could update the ZK client lib to do this. It
> would be invisible to the client application (your code) itself.
I don't think that's a bad idea, and the general approach in ZK-146 of
using an interface that gets called to retrieve the list of hosts
seems good (so
Allow dynamic addition/removal of server nodes in the client API
Key: ZOOKEEPER-762
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-762
Project: Zookeeper
Issue Type: Sub-
[
https://issues.apache.org/jira/browse/ZOOKEEPER-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Hunt updated ZOOKEEPER-747:
---
Status: Resolved (was: Patch Available)
Hadoop Flags: [Reviewed]
Resolutio
[
https://issues.apache.org/jira/browse/ZOOKEEPER-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12863538#action_12863538
]
Patrick Hunt commented on ZOOKEEPER-737:
+1 latest patch looks good to me. Did a
[
https://issues.apache.org/jira/browse/ZOOKEEPER-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12863562#action_12863562
]
Mahadev konar commented on ZOOKEEPER-737:
-
ben, can you take a look at it? We sh
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
[
https://issues.apache.org/jira/browse/ZOOKEEPER-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12863649#action_12863649
]
Benjamin Reed commented on ZOOKEEPER-737:
-
+1 great job mahadev
> some 4 letter
[
https://issues.apache.org/jira/browse/ZOOKEEPER-737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Reed updated ZOOKEEPER-737:
Hadoop Flags: [Reviewed]
> some 4 letter words may fail with netcat (nc)
> -
>
>
> 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
25 matches
Mail list logo
