Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Plain View
Zookeeper, mail # user - Adding watcher on the same zk node multiple times - jute.maxbuffer


+
Parkirat Bagga 2012-10-19, 05:43
+
Daniel Gómez Ferro 2012-10-19, 09:59
+
Parkirat Bagga 2012-10-19, 11:01
Copy link to this message
-
Re: Adding watcher on the same zk node multiple times - jute.maxbuffer
Ben Bangert 2012-10-19, 16:14
On Oct 19, 2012, at 4:01 AM, Parkirat Bagga <[EMAIL PROTECTED]> wrote:

> Thanks Daniel for the reply.
>
> My question is little different. May be I have not explained it well.
>
> My question is,  I have a watcher object say "mywatch".
>
> Now, if on a zk node say "/mynode", I add "mywatch" watcher 400K times or
> more, and a disconnection happens at zk and all the watcher will get
> re-registered again.
>
> Can this result in connection - disconnection continuously, because of the
> value of jute.maxbuffer is 1mb?
>
> I may get only 1 notification for all my watchers but, I want to know, if
> the same watcher is registered 400k times on the same node, there are
> actually 400k watchers present or its being overridden every time as its
> essentially the same watcher being registered on the same node.

If you make 400k objects, there are 400k watcher objects. Internally, the clients use a set per path and watch type, so that all 400k objects are tracked on the client-side as associated with the watch path/type. When the watch is triggered, the client goes through all 400k watch objects triggering them.

Technically, the Zookeeper protocol does not broadcast anything for disconnection, handling the disconnect and triggering all the watches is purely a client-side library implementation detail. If the client re-registers them, then its up to how the client implementation handles this. I'd imagine it would send 400k separate watch requests.

Now, if this watch object is not unique per call, that is you're using the same exact object and telling it to watch a node over and over, then its most likely registered just once client-side, and will result in just a single watch re-registration upon reconnect. This is because the internal implementation uses a set for the client-side watch path/type, and registering the same one over and over will not alter the set of unique watchers for the path/type.

Does that help?

Cheers,
Ben
+
Parkirat Bagga 2012-10-19, 16:38