Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

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


Copy link to this message
-
Re: Adding watcher on the same zk node multiple times - jute.maxbuffer
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
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB