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: <FF60961A-650C-4AD4-B1F8-E92FA920E6E9@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> <CAFBpvfswFqFki4afB-0qRz7hNxVH7H53+9+V1aZNUmxNN=uLmw@mail.gmail.com>
 <FF60961A-650C-4AD4-B1F8-E92FA920E6E9@gmail.com>
From: Alexander Shraer <shralex@gmail.com>
Date: Tue, 14 Nov 2017 08:55:42 -0800
Message-ID: <CANcXBFMGghHV96qb1ie-_-XqcAgZBZ5=jYmMNe265_qy2KSU7g@mail.gmail.com>
Subject: Re: how zookeeper promise FIFO client order
To: "dev@zookeeper.apache.org" <dev@zookeeper.apache.org>
Cc: "user@zookeeper.apache.org" <user@zookeeper.apache.org>, andor@cloudera.com, afine@apache.org
Content-Type: multipart/alternative; boundary="f403045c82041cd62f055df4437d"
archived-at: Tue, 14 Nov 2017 16:56:09 -0000

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

Hi,

Specific implementations of Raft may guarantee client program order, but I
don't think that it directly follows from tcp order + state machine.
It matters whether commands are committed to the log according to program
order. For example, here's an implementation that seems
to be doing this:
http://atomix.io/copycat/docs/client-interaction/#preserving-program-order =
In
any case, this is probably not the right forum
for Raft questions :)

I'm not sure we want to do command queueing on the leader like in the link
above or maybe just reset the client session if we're missing requests. In
any case,
perhaps this is worth a discussion on a JIRA. What do others think ?
Baotiao, would you like to open one ?

Thanks,
Alex


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

> Hi Andor
>
> Another question is that if zookeeper only promise channel FIFO order, I
> think raft that build upon tcp also promise FIFO client order, since ther
> FIFO order is promise by the tcp connection, and almost all consensus
> algorithm apply the log to state machine in order.
>
> if I misunderstand any thing, please tell me.
>
>
>
> ----------------------------------------
>
> 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 13:08, Andor Molnar <andor@cloudera.com> wrote:
> >
> > Oh, I see your problem now.
> > Abe is right, you can find find the best answer in the book and the sho=
rt
> > 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
> race
> >>> 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
> that
> >>>> 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 operati=
on
> is
> >>>> on
> >>>> the way"?
> >>>>
> >>>> If "set b=3D1" is accepted by the leader, the client won't have to
> resend
> >>>> it
> >>>> on reconnect.
> >>>>
> >>>> Regards,
> >>>> Andor
> >>>>
> >>>>
> >>>> On Mon, Nov 13, 2017 at 5:01 AM, =E9=99=88=E5=AE=97=E5=BF=97 <baotia=
o@gmail.com> wrote:
> >>>>
> >>>>> I want to know in the following situation, how zookeeper promise
> client
> >>>>> 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=
 the
> >>>>> leader, then there is something wrong with this tcp connection, thi=
s
> >> 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
> sent
> >> 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/
> baotiao
> >>>
> >>>>> Git: https://github.com/baotiao
> >>>>>
> >>
> >>
>
>

--f403045c82041cd62f055df4437d--