Mailing-List: contact user-help@zookeeper.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@zookeeper.apache.org
Received-SPF: pass (athena.apache.org: domain of cf@renttherunway.com
 designates 209.85.217.178 as permitted sender)
MIME-Version: 1.0
Sender: cf@renttherunway.com
In-Reply-To: 
 <CAMUR=WgyvhBw2JH+3n35DhYh6E27QKmcuW0rUcCoDF8kL7dx7A@mail.gmail.com>
References: 
 <CAP8NC1175_Z0aWvdgyQFoKWh2RJcMwZkHALQ5KSbgix74Yec0w@mail.gmail.com>
	<CAMUR=WgyvhBw2JH+3n35DhYh6E27QKmcuW0rUcCoDF8kL7dx7A@mail.gmail.com>
Date: Tue, 4 Mar 2014 15:25:49 -0500
Message-ID: 
 <CAKF1A=vKzvXmKF8SHUjyjAbcHEqWFJwTKzZ8WjvpKJkfdmzS6A@mail.gmail.com>
Subject: Re: sometimes I can't read data I just wrote..race condition or
 misunderstanding?
From: Camille Fournier <camille@apache.org>
To: "bookkeeper-user@zookeeper.apache.org" <user@zookeeper.apache.org>
Content-Type: multipart/alternative; boundary=001a1136c856b4c9f004f3cdb536

--001a1136c856b4c9f004f3cdb536
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Is the same client issuing the write and the read? If so, you should see
the data you wrote. Otherwise, you may be connected to a lagging client, as
Raul says.

C


On Tue, Mar 4, 2014 at 3:22 PM, Ra=C3=BAl Guti=C3=A9rrez Segal=C3=A9s
<rgs@itevenworks.net>wrote:

> On 4 March 2014 07:21, Brian Tarbox <briantarbox@gmail.com> wrote:
>
> > We're running a five node cluster in AWS and sometimes if I do a read
> > immediately after doing a write ZK does not find the data I just wrote.
> >
> > I may just have a flawed model but is this a case of "writes go to the
> > master, while reads can go to any node in the cluster?".  We are thinki=
ng
> > that perhaps our write went to the master and then our read went to a
> > follower that hadn't gotten the write yet?
> >
>
> Perhaps you can call sync() to ensure reads after writes?
>
>
> > Along the same lines...when does a watch fire?  After the leader has th=
e
> > change or after all followers have gotten the change?
> >
>
> The pipeline is, in a poor's man diagram, as follow:
>
>
> client =E2=86=92 write request =E2=86=92 zk_server_1
>                                               =E2=86=93
>                                               =E2=86=93
>                       write request is sent to the leader
>                                               =E2=86=93
>                                               =E2=86=93
>              leader fans out a transaction proposal to all followers
>                                               =E2=86=93
>                                               =E2=86=93
>             =E2=86=93                =E2=86=93                           =
=E2=86=93
> =E2=86=93
>        follower 1     follower 2              follower 3         follower=
 4
>                                               =E2=86=93
>                                               =E2=86=93
>                followers, non-synchronously, acknowledge the proposal
>                                               =E2=86=93
>                                               =E2=86=93
>      when the leader gets a sufficient number of acks (from a "majority")
> it fans out COMMIT msgs to followers
>                                               =E2=86=93
>                                               =E2=86=93
>             =E2=86=93                =E2=86=93                           =
=E2=86=93
> =E2=86=93
>        follower 1     follower 2              follower 3         follower=
 4
>                                               =E2=86=93
>                                               =E2=86=93
>        followers will then apply the write which triggers watches, that i=
n
> turn will then flow to listening clients...
>
>
> Hth,
> -rgs
>

--001a1136c856b4c9f004f3cdb536--