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 476881994D for ; Mon, 7 Mar 2016 15:58:17 +0000 (UTC) Received: (qmail 82607 invoked by uid 500); 7 Mar 2016 15:58:16 -0000 Delivered-To: apmail-zookeeper-user-archive@zookeeper.apache.org Received: (qmail 82557 invoked by uid 500); 7 Mar 2016 15:58:16 -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 82389 invoked by uid 500); 7 Mar 2016 15:58:15 -0000 Delivered-To: apmail-hadoop-zookeeper-user@hadoop.apache.org Received: (qmail 82381 invoked by uid 99); 7 Mar 2016 15:58:15 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 07 Mar 2016 15:58:15 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 688541A0268 for ; Mon, 7 Mar 2016 15:58:15 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.862 X-Spam-Level: ** X-Spam-Status: No, score=2.862 tagged_above=-999 required=6.31 tests=[FREEMAIL_ENVFROM_END_DIGIT=0.25, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=2, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URI_HEX=1.313] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id 3vlqUZjDunNN for ; Mon, 7 Mar 2016 15:58:13 +0000 (UTC) Received: from mail-io0-f171.google.com (mail-io0-f171.google.com [209.85.223.171]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 89F385FAC4 for ; Mon, 7 Mar 2016 15:58:12 +0000 (UTC) Received: by mail-io0-f171.google.com with SMTP id g203so135717761iof.2 for ; Mon, 07 Mar 2016 07:58:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kCxnzwmsY4QKEofvakj9EETYQRUg0FzZmOIB05vDs9k=; b=Wa/0Kaowo1Dq1aIFan/uwu8f3c2bcHSjnp8pfnQY2rYG9zrs5Xb1q/U6485uoIRXRN PaPyTP4v02V0yTftHIq6NnhW4oRqhZkz8YaZSgefQMzA9aPj5s1xT62PIrc36ws+R/OI TQHEG8JTBGwalXwmByJVsr4A1qKHUnE3PCNrv+NpESoKkLW7cOiqkzUjwftgBhqT1rvg kPjt+NMUv+fihFxjXe8L+u6EiHGs5zIJHu1ejPdM8R0v+llkJbVnDngtD3h+nn21TJuu buPj3OoS2C0stnm/uykeYJA7BTJ2shKNf6VUf3/ywAwmR0Fg0IfBTReGPRNjF5/dla6e it3A== X-Gm-Message-State: AD7BkJJ6byIwPKhr90Y6c6vz1vBLplWgYbZ8fVbksBq8noru7eiY56YWujLgS6rSRHUH1Cj8YYnl4y2APaUGQQ== X-Received: by 10.107.36.80 with SMTP id k77mr21592463iok.121.1457366285633; Mon, 07 Mar 2016 07:58:05 -0800 (PST) MIME-Version: 1.0 References: <1456619646715-7582086.post@n2.nabble.com> <1457337445495-7582099.post@n2.nabble.com> In-Reply-To: From: Vitalii Tymchyshyn Date: Mon, 07 Mar 2016 15:57:56 +0000 Message-ID: Subject: Re: zookeeper client session write-read consistency To: user@zookeeper.apache.org Cc: zookeeper-user@hadoop.apache.org Content-Type: multipart/alternative; boundary=001a1141909ec34dec052d778785 --001a1141909ec34dec052d778785 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable How about a reconnect to another server between the write and the next read= ? Curious about both cases maintaining the session and establishing a new one with some higher level retrier like Curator. =D0=9F=D0=BD, 7 =D0=B1=D0=B5=D1=80. 2016 07:50 =D0=BA=D0=BE=D1=80=D0=B8=D1= =81=D1=82=D1=83=D0=B2=D0=B0=D1=87 Alexander Shraer =D0= =BF=D0=B8=D1=88=D0=B5: > The server to which the client is connected will buffer the read until th= e > write is executed and applied to its state, so the read will necessarily > return a value at least as recent as the one written by the write in your > example. ZK guarantees that async operations are executed in order of > invocation. > On Mar 6, 2016 23:57, "wayne" wrote: > > Thanks Chris! I appreciate the answer a lot! > > What you said made perfect sense in the case that request are sent > synchronously (which was my assumption :)). What if the requests are sent > asynchronously? e.g. If I call AsyncWrite, AsyncRead within a session, wh= en > the AsyncRead is executed, the previous AsyncWrite's result might not hav= e > been returned to the client yet, then there is no way for the client to > know > the previous AsyncWrite's zxid, correct? In that case, could the situatio= n > I > mentioned in my previous post happen? > > > > -- > View this message in context: > > http://zookeeper-user.578899.n2.nabble.com/zookeeper-client-session-write= -read-consistency-tp7579330p7582099.html > Sent from the zookeeper-user mailing list archive at Nabble.com. > --001a1141909ec34dec052d778785--