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 >> Understanding event interleaving


Copy link to this message
-
Re: Understanding event interleaving
If I understand well your scenario, R will receive Version 2 and and event
is delivered to caller (R). In this scenario, the thread that has
registered the watch on node Z has to still be alive to receive the event.

BR//Bahman
On Thu, May 23, 2013 at 8:47 AM, Scott Fines <[EMAIL PROTECTED]> wrote:

> Hello all,
>
> This is perhaps a silly question, but one I'm not clear on.
>
> Suppose you have two clients (R and W), and they are interacting through
> znode Z. Now consider the following situation:
>
> 0. Z at version 1
> 1. R begins getData(Z) (attach Watcher)
> 2. W begins setData(Z)
> 3. W completed setData(Z) successfully --e.g. the client call returns with
> no errors
> 4. R completes getData(Z) successfully -- e.g. the client call returns
> with no errors
>
> My questions are then:
>
> 1. What version of data will R receive? Version 1, or Version 2? My
> assumption here is that R would receive version 1 of the data--is that
> correct?
>
> 2. Does R's watch fire with the changes made by W? If so, is a WatchEvent
> delivered all the way to the caller? A comment made on ZOOKEEPER-1505 (
> https://issues.apache.org/jira/browse/ZOOKEEPER-1505) implies that it
> would not, but I'm unclear if that is in reference to the proposed changes
> or not.
>
> Thanks for your help!
>
> Scott Fines
>
>
>
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