On 05/27/2010 06:54 AM, Dave Wright wrote:
The documentation is inconsistent on what happens to watches after a
disconnection.
The web documentation states:
"Watches will not be received while disconnected from a server. When a
client reconnects, any previously registered watches wi
The documentation is inconsistent on what happens to watches after a
disconnection.
The web documentation states:
"Watches will not be received while disconnected from a server. When a
client reconnects, any previously registered watches will be
reregistered and triggered if needed. In ge
, since they still send all messages required for the
agreement phase of our update protocol.
In this way, I expect you to be able to scale to the number of watches
you're talking about, assuming you'll be able to add enough servers.
To compute the number of zookeeper servers you need,
4.0.0 at the latest, and it might be possible to have
it for 3.3.0.
-Flavio
On Aug 30, 2009, at 4:32 AM, Mahadev Konar wrote:
Hi Avinash,
100K clients would be a stretch. We have never tested at that scale.
100K watches should not be a problem at all. I am more concerened
about the
numb
Hi Avinash,
100K clients would be a stretch. We have never tested at that scale.
100K watches should not be a problem at all. I am more concerened about the
number of client connections that would result to each of the zookeeper
servers.
In case of 5 servers, that would be 20K persistent
That is probably a bit beyond reasonable levels of scaling. For one thing,
putting 100,000 machines close together in a network is a bit tricky. The
two major limitations are likely to be memory for keeping the watches on the
server side and bandwidth for publishing the notifications.
That said
Hi All
Is it possible to have 100K machines register for a watch on a znode? I mean
theoritically yes it should work but ZK scale to these many instances when
it comes to delivering watch notifications? Perhaps no one has practical
experience in dealing with this but is there any fundamental limita
to the get function.
Patrick
Erik Holstad wrote:
Hi Avinash!
I'm just a beginner so not really sure if I no how everything works, but
this is my understanding of
how watches work.
Setting a watch on node a from client c.
A change to a happens and a notification is sent over to c. The notification
Avinash Lakshman wrote:
Hi All
Suppose I have a znode, say /Me, and have three nodes A, B and C who have
set watches on this znode. Now suppose some process changes some value on
/Me then watches get delivered to A, B and C. Now if at that instant of time
C were down I could always read the
Hi Avinash!
I'm just a beginner so not really sure if I no how everything works, but
this is my understanding of
how watches work.
Setting a watch on node a from client c.
A change to a happens and a notification is sent over to c. The notification
doesn't include any data but just
Hi All
Suppose I have a znode, say /Me, and have three nodes A, B and C who have
set watches on this znode. Now suppose some process changes some value on
/Me then watches get delivered to A, B and C. Now if at that instant of time
C were down I could always read the znode on coming back up
No. As Stu said, watches are a one-time thing. In addition, multiple
changes may be signaled with a single notification on a watch.
So the guarantee is that you will get at least one notification when there
are one or more changes. You need to make sure that when you get the
children in
A watch is a 1-time event: after the watch is triggered, you will need to reset
the watch to be notified again.
-Original Message-
From: "Avinash Lakshman"
Sent: Thursday, June 4, 2009 10:52pm
To: zookeeper-user@hadoop.apache.org
Subject: Re: Watches
So I use the getChildre
So I use the getChildren() API to set a watch on the parent and every
process is doing it now. If I am create 10 sub znodes under /A should my
watch get triggered 10 times. Is this the expected behavior? Should I get
one per sub znode? I don't seem to get 10 watches triggered but that could
All the processes should put watches on that node.
I think that the problem here is that the answer is too simple. You seem to
be looking for something fancy while ZK provides something simple.
On Thu, Jun 4, 2009 at 12:40 PM, Avinash Lakshman <
avinash.laksh...@gmail.com> wrote:
>
gt;> if ( stat == null )
>>> {
>>>zk_.create("/A", new byte[0], Ids.OPEN_ACL_UNSAFE,
>>> CreateMode.PERSISTENT);
>>> }
>>>
Shouldn't it be zk.exists("/A" + path) ?
Also you would create zk.create("/A" + path) ?
No?
Al
Avinash Lakshman wrote:
> I want to get notified whenever any sub znode is created under /A. Only one
> process amongst many will create these sub znodes. But everyone needs to be
> notified about this
Right. So, each process that needs to be notified should call
zk_.watchChildren( "/A", true )
ny watch when I add the sub znodes. What am
> I
> > doing wrong
>
> Try:
>
> zk_.watchChildren( "/A", true )
>
> What you are doing watches changes to the data at /A, not its children.
>
> From the javadocs:
>
>
> getChildren
>
&
b znodes. What am I
> doing wrong
Try:
zk_.watchChildren( "/A", true )
What you are doing watches changes to the data at /A, not its children.
>From the javadocs:
getChildren
public List
<http://java.sun.com/javase/6/docs/api/java/util/List.html?is-e
Hi All
I have a znode named /A. Now I will over time create znodes below it such
/A/A1, /A/A2, ..., /A/An etc. Now every time I create this sub znode I need
to have all my processes notified. Can I get by just setting one watch on
/A? So my set up looks as follows:
stat = zk_.exists(path + "/A",
Hi Satish,
If you call getChildren(rootPath, true), it will set the watch and doing
the same operration with false _DOES NOT_ remove the watch.
In case you want different behaviour from these 2 different calls, you
should use the call back specific api;s
Getchildren(string path, watcher watcher
HI Kevin,
The watches are just a signal that something on the node that you were
watching has changed. It does not get you the diff back saying what changed.
So you will have to read/stat the node in order for you to check what
changed.
The way the watches are implemented in Zookeeper is such
> Because watches are one time triggers and there is latency between getting
the
> event and sending a new request to get a watch you cannot reliably see
every
> change that happens to a node in ZooKeeper. Be prepared to handle the case
where
> the znode changes multiple times between
Watches also do not have any data associated with them, so even if they were
not one-time, you would not get any extra information and you have the
potential of generating a lot of extra network traffic.
ben
-Original Message-
From: Mahadev Konar [mailto:[EMAIL PROTECTED]
Sent
Hi Thomas,
Yes, watches are one time triggers. Watches are supposed to be lighweight
and local to the server you are connected to.
We designed it such that it has minimum load impact on the servers.
mahadev
On 11/18/08 5:58 AM, "Kiesslich, Thomas" <[EMAIL PROTECTED]>
wrote:
&
Hi,
A watch is designed as a one time trigger. Why have you designed it that way?
Why not as a normal listener?
Mit freundlichen Grüßen / With best regards
Thomas Kießlich
Siemens Enterprise Communications GmbH & Co. KG
HiPath Applications
SEN LIP DA 11
Schertlinstr. 8
81379 Munich, Ge
26 matches
Mail list logo
