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: <CAGbZs7g1Dt6QXZo1S0DLFrJ6X5SxvXXFR+j2OJeyksGBVyGe-Q@mail.gmail.com>
References: <CAGbZs7g1Dt6QXZo1S0DLFrJ6X5SxvXXFR+j2OJeyksGBVyGe-Q@mail.gmail.com>
From: Andor Molnar <andor@cloudera.com>
Date: Mon, 13 Nov 2017 15:17:35 +0100
Message-ID: <CAFBpvfsOVjTV3tz+TbFmxJRJwwS6L9qDemCzOGHij_iicuVoWQ@mail.gmail.com>
Subject: Re: how zookeeper promise FIFO client order
To: user@zookeeper.apache.org
Content-Type: multipart/alternative; boundary="f4030435b33498a61a055dddee2c"
archived-at: Mon, 13 Nov 2017 14:17:42 -0000

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

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 operation is o=
n
the way"?

If "set b=3D1" is accepted by the leader, the client won't have to resend i=
t
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 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, this clie=
nt
> reconnect a new tcp connection to the leader, but the set b =3D 1 operati=
on
> is on the way. then the client will use the new tcp connection to sent se=
t
> 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
>

--f4030435b33498a61a055dddee2c--