Mailing-List: contact user-help@zookeeper.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@zookeeper.apache.org
MIME-Version: 1.0
In-Reply-To: <A750D3FD-D83A-47B1-AA8D-A0EBD9447C90@gmail.com>
References: <CAGbZs7g1Dt6QXZo1S0DLFrJ6X5SxvXXFR+j2OJeyksGBVyGe-Q@mail.gmail.com>
 <CAFBpvfsOVjTV3tz+TbFmxJRJwwS6L9qDemCzOGHij_iicuVoWQ@mail.gmail.com>
 <1510618325.2966293.1171459416.240F2D1D@webmail.messagingengine.com> <A750D3FD-D83A-47B1-AA8D-A0EBD9447C90@gmail.com>
From: Andor Molnar <andor@cloudera.com>
Date: Tue, 14 Nov 2017 06:08:00 +0100
Message-ID: <CAFBpvfswFqFki4afB-0qRz7hNxVH7H53+9+V1aZNUmxNN=uLmw@mail.gmail.com>
Subject: Re: how zookeeper promise FIFO client order
To: user@zookeeper.apache.org
Cc: dev@zookeeper.apache.org, afine@apache.org
Content-Type: multipart/alternative; boundary="94eb2c1c1008f7d520055dea5eb8"
archived-at: Tue, 14 Nov 2017 05:08:08 -0000

--94eb2c1c1008f7d520055dea5eb8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Oh, I see your problem now.
Abe is right, you can find find the best answer in the book and the short
answer is, yes, it only promises channel fifo order.

Regards,
Andor


On Tue, Nov 14, 2017 at 4:04 AM, baotiao <baotiao@gmail.com> wrote:

> Hello Abraham
>
> right, exactly.
>
> my confusion is that the client FIFO order is for a client or only for a
> tcp connection
> ----------------------------------------
>
> Github: https://github.com/baotiao
> Blog: http://baotiao.github.io/
> Stackoverflow: http://stackoverflow.com/users/634415/baotiao
> Linkedin: http://www.linkedin.com/profile/view?id=3D145231990
>
> > On 14 Nov 2017, at 08:12, Abraham Fine <afine@apache.org> wrote:
> >
> > Hello-
> >
> > My understanding is that the question is about the possibility of a rac=
e
> > condition between two client requests. I would take a look at the
> > section "Order in the Presence of Connection Loss" in the "ZooKeeper:
> > Distributed Process Coordination" book for the best answer to this
> > question.
> >
> > Thanks,
> > Abe
> >
> > On Mon, Nov 13, 2017, at 06:17, Andor Molnar wrote:
> >> Hi baotiao,
> >>
> >> First, requests are acknowledged back to the client once the leader
> >> accepted and written them in its transaction log, which guarantees tha=
t
> >> in
> >> case of a crash, pending transactions can be processed on restart.
> >> Transactions IDs (zxid) are incremental and generated by the leader.
> >> Second, Zab guarantees that if the leader broadcast T and T' in that
> >> order,
> >> each server must commit T before committing T'.
> >>
> >> With these 2 promises, I believe, that FIFO is guaranteed by Zookeeper=
.
> >>
> >> Would you please clarify that what do you mean by "set b=3D1 operation=
 is
> >> on
> >> the way"?
> >>
> >> If "set b=3D1" is accepted by the leader, the client won't have to res=
end
> >> it
> >> on reconnect.
> >>
> >> Regards,
> >> Andor
> >>
> >>
> >> On Mon, Nov 13, 2017 at 5:01 AM, =E9=99=88=E5=AE=97=E5=BF=97 <baotiao@=
gmail.com> wrote:
> >>
> >>> I want to know in the following situation, how zookeeper promise clie=
nt
> >>> FIFO order.
> >>>
> >>> the client sent three operation to server, set a =3D 1, set b =3D 1, =
set
> ready
> >>> =3D true.
> >>>
> >>> is it possible to this situation that the set a =3D 1 is process by t=
he
> >>> leader, then there is something wrong with this tcp connection, this
> client
> >>> reconnect a new tcp connection to the leader, but the set b =3D 1
> operation
> >>> is on the way. then the client will use the new tcp connection to sen=
t
> set
> >>> ready =3D true operation. so the set a =3D 1 is operated, set b =3D 1=
 is not
> and
> >>> set ready =3D true is operated too.
> >>>
> >>> the question is how zab promise client FIFO order?
> >>>
> >>> zab can resend all the operation that hasn't be replied from the
> leader.
> >>> then in this situation, when the client reconnect to the leader, it
> will
> >>> resent the operation set b =3D 1, set ready =3D true.
> >>>
> >>> is this the way the zab used to primise FIFO order?
> >>>
> >>> Thank you all
> >>>
> >>> --
> >>> ---
> >>> Blog: http://www.chenzongzhi.info
> >>> Twitter: https://twitter.com/baotiao <https://twitter.com/#%21/baotia=
o
> >
> >>> Git: https://github.com/baotiao
> >>>
>
>

--94eb2c1c1008f7d520055dea5eb8--