Return-Path: Delivered-To: apmail-hadoop-zookeeper-user-archive@minotaur.apache.org Received: (qmail 63059 invoked from network); 13 Sep 2010 21:02:51 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 13 Sep 2010 21:02:51 -0000 Received: (qmail 3951 invoked by uid 500); 13 Sep 2010 21:02:51 -0000 Delivered-To: apmail-hadoop-zookeeper-user-archive@hadoop.apache.org Received: (qmail 3898 invoked by uid 500); 13 Sep 2010 21:02:50 -0000 Mailing-List: contact zookeeper-user-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: zookeeper-user@hadoop.apache.org Delivered-To: mailing list zookeeper-user@hadoop.apache.org Received: (qmail 3890 invoked by uid 99); 13 Sep 2010 21:02:50 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 13 Sep 2010 21:02:50 +0000 X-ASF-Spam-Status: No, hits=3.3 required=10.0 tests=HTML_MESSAGE,NO_RDNS_DOTCOM_HELO,RCVD_IN_DNSWL_NONE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [216.145.54.171] (HELO mrout1.yahoo.com) (216.145.54.171) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 13 Sep 2010 21:02:44 +0000 Received: from SP2-EX07CAS04.ds.corp.yahoo.com (sp2-ex07cas04.corp.sp2.yahoo.com [98.137.59.5]) by mrout1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o8DL1mc2049246; Mon, 13 Sep 2010 14:01:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:from:to:cc:date:subject:thread-topic: thread-index:message-id:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:mime-version; b=o6GY/I9QtdwGKmbYcPa66GWvXSKf6esXkbuKXuFMPYabQF0k6ZjqkZzvzKvxElUR Received: from SP2-EX07VS04.ds.corp.yahoo.com ([98.137.59.33]) by SP2-EX07CAS04.ds.corp.yahoo.com ([98.137.59.5]) with mapi; Mon, 13 Sep 2010 16:01:48 -0500 From: Mahadev Konar To: "todd@spidertracks.co.nz" CC: "zookeeper-user@hadoop.apache.org" Date: Mon, 13 Sep 2010 16:01:46 -0500 Subject: Re: Receiving create events for self with synchronous create Thread-Topic: Receiving create events for self with synchronous create Thread-Index: ActFlXJGBKXLWL6kSkuVcPfX9r0MvQN8W3Ks Message-ID: In-Reply-To: <1282878593.4963.94.camel@greenlantern.local> Accept-Language: en, en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en, en-US Content-Type: multipart/alternative; boundary="_000_C8B3DF4A42143mahadevyahooinccom_" MIME-Version: 1.0 --_000_C8B3DF4A42143mahadevyahooinccom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Todd, Sorry for my late response. I had marked this email to respond but couldn'= t find the time :). Did you figure this out? It mostly looks like that as s= oon as you set a watch on /follower, some other node instantly creates anot= her child of /follower? Could that be the case? Thanks mahadev On 8/26/10 8:09 PM, "Todd Nine" wrote: Sure thing. The FollowerWatcher class is instantiated by the IClusterManag= er implementation. It then performs the following FollowerWatcher.init() which is intended to do the following. 1. Create our follower node so that other nodes know we exist at path "/com= /spidertracks/aviator/cluster/follower/10.0.1.1" where the last node is an= ephemeral node with the internal IP address of the node. These are lines = 67 through 72. 2. Signal to the clusterManager that the cluster has changed (line 79). Ul= timately the clusterManager will perform a barrier for partitioning data ( = a separate watcher) 3. Register a watcher to receive all future events on the follower path "/c= om/spidertracks/aviator/cluster/follower/" line 81. Then we have the following characteristics in the watcher 1. If a node has been added or deleted from the children of "/com/spidertra= cks/aviator/cluster/follower" then continue. Otherwise, ignore the event. = Lines 33 through 44 2. If this was an event we should process our cluster has changed, signal t= o the CusterManager that a node has either been added or removed. line 51. I'm trying to encapsulate the detection of additions and deletions of child= nodes within this Watcher. All other events that occur due to a node bein= g added or deleted should be handled externally by the clustermanager. Thanks, Todd On Thu, 2010-08-26 at 19:26 -0700, Mahadev Konar wrote: Hi Todd, The code that you point to, I am not able to make out the sequence of st= eps. Can you be more clear on what you are trying to do in terms of zookeepe= r api? Thanks mahadev On 8/26/10 5:58 PM, "Todd Nine" wrote: Hi all, I'm running into a strange issue I could use a hand with. I've implemented leader election, and this is working well. I'm now implementing a follower queue with ephemeral nodes. I have an interface IClusterManager which simply has the api "clusterChanged". I don't care if nodes are added or deleted, I always want to fire this event. I have the following basic algorithm. init Create a path with "/follower/"+mynode name fire the clusterChangedEvent Watch set the event watcher on the path "/follower". watch: reset the watch on "/follower" if event is not a NodeDeleted or NodeCreated, ignore fire the clustermanager event this seems pretty straightforward. Here is what I'm expecting 1. Create my node path 2. fire the clusterChanged event 3. Set watch on "/follower" 4. Receive watch events for changes from any other nodes. What's actually happening 1. Create my node path 2. fire the clusterChanged event 3. Set Watch on "/follower" 4. Receive watch event for node created in step 1 5. Receive future watch events for changes from any other nodes. Here is my code. Since I set the watch after I create the node, I'm not expecting to receive the event for it. Am I doing something incorrectly in creating my watch? Here is my code. http://pastebin.com/zDXgLagd Thanks, Todd --_000_C8B3DF4A42143mahadevyahooinccom_--