Return-Path: X-Original-To: apmail-zookeeper-user-archive@www.apache.org Delivered-To: apmail-zookeeper-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id F184A395C for ; Fri, 6 May 2011 05:30:30 +0000 (UTC) Received: (qmail 93658 invoked by uid 500); 6 May 2011 05:30:30 -0000 Delivered-To: apmail-zookeeper-user-archive@zookeeper.apache.org Received: (qmail 93201 invoked by uid 500); 6 May 2011 05:30:30 -0000 Mailing-List: contact user-help@zookeeper.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@zookeeper.apache.org Delivered-To: mailing list user@zookeeper.apache.org Received: (qmail 93192 invoked by uid 99); 6 May 2011 05:30:28 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 06 May 2011 05:30:28 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of ted.dunning@gmail.com designates 209.85.220.170 as permitted sender) Received: from [209.85.220.170] (HELO mail-vx0-f170.google.com) (209.85.220.170) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 06 May 2011 05:30:20 +0000 Received: by vxb40 with SMTP id 40so4208795vxb.15 for ; Thu, 05 May 2011 22:29:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=8L8EDsPO7MZpnWUMKYqHlifMhTt6m0DJ7HWpuB49rxw=; b=Gs8cA4lCRKVap7yOzzNBQuWLY4KpwgL0ygVpIaWpKPWrP/hHhv2nWTRu5NoFIQjDG4 Jd7YdG0bvhkQOvTCRie307FSiBxYHwZ+Mkg54mTad1c5MSgEoXaO25U/i/0MNDVzSU3B tEw0AhGU5orc0kG29BNgPtwCZda9vH+KS8e1Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=Ckr+AyPn3EOk40iv1SA9m5RlFurE5n5tYokvbvKm41HGs2oWE5aKkFceahUdBFUk+r U16qfqTG5Ey0RDRqI7qVAa+VMTFlPYSaq6I59B7jkAae448MbZ+4MzxZLLWnY3YFx+FX dIC7gjezW/PByxFkfO2+OPLn9A/xRvxaySOMo= Received: by 10.52.67.167 with SMTP id o7mr2176407vdt.240.1304659799099; Thu, 05 May 2011 22:29:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.116.42 with HTTP; Thu, 5 May 2011 22:29:39 -0700 (PDT) In-Reply-To: References: From: Ted Dunning Date: Thu, 5 May 2011 22:29:39 -0700 Message-ID: Subject: Re: What is the order of read watch and write completion? To: user@zookeeper.apache.org Content-Type: multipart/alternative; boundary=20cf307f3b5ce0caaa04a294c72d X-Virus-Checked: Checked by ClamAV on apache.org --20cf307f3b5ce0caaa04a294c72d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This example seems a bit confused. If there is a watch on /b and /a is changed, then the watch on /b will not be triggered. Can you rephrase your question? On Thu, May 5, 2011 at 8:47 PM, =E9=82=A2=E8=BF=AA=E4=BE=83 wrote: > Hi, All, > > I'm not sure whether the response (from the client perspective, the > completion callback or the return of a sync call) to a success write > (create, delete, etc) is also queued in the right place among read > completion and read watch. > > In detail, for example the current view is: > /a: oldA > /b: oldB > > And from the perspective of the zk server, it handles the following two > change in the shown order: > a) /a changes to newA > b) /b changes to newB > > I understand, if Tom sets the read watch previously, before reading out t= he > new content of "/b", Tom will get watch notification of "/a". > My question is if Tom is not reading, but writing. It is Tom that changes > the content of /b. Then is there guarantee that the watch notification of > "/a" will preceed the completion callback (if Tom asetData()) and the > return > of setData? > > In other words, will the server queue the response to the client's write > request only after previous writes are locally played and triggered watch= es > are handled and queued into TCP sending tunnel? > Or say, is a success response to a write request a part of a consistent > view > for a client? > > XING Dikan > --20cf307f3b5ce0caaa04a294c72d--