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 Plain View
Zookeeper >> mail # user >> Do we need a 'sync' to make sure no stale ephemeral nodes observed (created by exipred session)


+
chao chu 2013-07-02, 16:44
+
Flavio Junqueira 2013-07-02, 16:54
+
chao chu 2013-07-02, 17:48
Copy link to this message
-
Re: Do we need a 'sync' to make sure no stale ephemeral nodes observed (created by exipred session)
If I understand your case correctly, then you'll set a watch on znode y with an exists call. If the exists returns that the node is there, then you'll receive a notification for the deletion of y later on. If the result of the exists call is that the znode doesn't exist, then you know that znode is gone. Does it make sense?

-Flavio
 
On Jul 2, 2013, at 7:48 PM, chao chu <[EMAIL PROTECTED]> wrote:

> Hi Flavio,
>
> Thanks for your reply. I think that's the exact thing I want to confirm:
> when we got the 'NodeDeleted' event due to session expiration, we shouldn't
> see the node anymore by calling 'getChildren' of the parent node.
>
> another related issue just came to my mind about the recipe to implement
> leader election, suppose the following sequences:
> 1. one participant (A) is watching the node (x) just before it
> 2. the node x that A was watching got deleted (due to session expiration or
> whatever)
> 3. once received the 'NodeDeleted' event, A should check what's the current
> node (the node now just before it) it should watch. However, these are two
> separate operations: 1) get all the child nodes, get the node (y) with the
> sequence just before A 2) A sets a watch on node y. between *getting the
> nodes* and *setting the watch on y*, the node y might also be got deleted.
>
> this should be a rare case and we can retry several times to lower the
> chance for this to happen further. But is there a better way to handle this?
>
>
> On Wed, Jul 3, 2013 at 12:54 AM, Flavio Junqueira <[EMAIL PROTECTED]>wrote:
>
>> Hi ChuChao,
>>
>> I'm not entirely sure I understand the question, so please send some more
>> info if this is not the answer you're looking for. In general you don't
>> have
>> to sync because the events are delivered in order, including the
>> notifications for say deleted znodes due to session expiration. An
>> exception
>> to this rule is the case in which two clients talk directly to each other
>> and a client needs to make sure that it doesn't read a stale version
>> compared to the other client. But, this is not the case for you, then you
>> don't need to sync, just watch for the znode being deleted and react
>> accordingly when you receive the notification.
>>
>> -Flavio
>>
>>
>>
>> -----Original Message-----
>> From: chao chu [mailto:[EMAIL PROTECTED]]
>> Sent: 02 July 2013 17:44
>> To: [EMAIL PROTECTED]
>> Subject: Do we need a 'sync' to make sure no stale ephemeral nodes observed
>> (created by exipred session)
>>
>> we know that for some performance reasons, different clients may have
>> slightly different views of znodes, for example, if client A updated node
>> a,
>> and it let client B to read the node a, client B might still read the old
>> data and it need a 'sync' to see the latest.
>>
>> Do we need to do the same thing when we concern about reading some stale
>> ephemeral nodes which are created by some already expired session?
>>
>> Thanks & Regards,
>>
>> --
>> ChuChao
>>
>>
>
>
> --
> ChuChao
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