Mailing-List: contact user-help@zookeeper.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@zookeeper.apache.org
From: baotiao <baotiao@gmail.com>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_2B517248-8C66-465B-8FC3-DD300472E92B"
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: how zookeeper promise FIFO client order
Date: Tue, 14 Nov 2017 10:59:32 +0800
References: <CAGbZs7g1Dt6QXZo1S0DLFrJ6X5SxvXXFR+j2OJeyksGBVyGe-Q@mail.gmail.com>
 <CAFBpvfsOVjTV3tz+TbFmxJRJwwS6L9qDemCzOGHij_iicuVoWQ@mail.gmail.com>
To: user@zookeeper.apache.org,
 andor@cloudera.com
In-Reply-To: <CAFBpvfsOVjTV3tz+TbFmxJRJwwS6L9qDemCzOGHij_iicuVoWQ@mail.gmail.com>
Message-Id: <7625B64C-CA1E-463B-83BF-DABBC83144FF@gmail.com>
archived-at: Tue, 14 Nov 2017 02:59:51 -0000

--Apple-Mail=_2B517248-8C66-465B-8FC3-DD300472E92B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Andor,

let me clarify the problem

since zookeeper promise that these operation are sending in pipeline, so =
the later operation don't need to wait the prior's confirmation. so the =
three operations
1. set a =3D 1
2. set b =3D 1
3. set ready =3D true

these three operations are sending in pipeline, the first operation set =
a =3D 1 is process ok, and the second operation set b =3D 1 is on the =
way. then there is something wrong with the leader, then the client =
connect a new tcp connection with the leader. And then the client send =
the last operation, since there is two tcp connection from client to =
server, even through the first is closed from the client's view, but =
there maybe still some redidual data, so we can't promise whether the =
second operation will arrive to the leader, and we also can't promise =
that the second operation arrive to the leader before the third one or =
after the third one. so this violate the client FIFO order.

my question here is that, is it zookeeper promise only channel FIFO =
order, not the client FIFO order. so if the client reconnect a new tcp =
connection, we can't promise the FIFO order.

Another question is that if zookeeper only promise channel FIFO order, I =
think raft which is build upon tcp also promise FIFO client order, since =
ther FIFO order is promise by the tcp connection, and almost any =
consensus algorithm combine with tcp will promise FIFO client order.

Thank you=20
----------------------------------------
=20
Github: https://github.com/baotiao
Blog: http://baotiao.github.io/
Stackoverflow: http://stackoverflow.com/users/634415/baotiao=20
Linkedin: http://www.linkedin.com/profile/view?id=3D145231990

> On 13 Nov 2017, at 22:17, Andor Molnar <andor@cloudera.com> wrote:
>=20
> Hi baotiao,
>=20
> 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'.
>=20
> With these 2 promises, I believe, that FIFO is guaranteed by =
Zookeeper.
>=20
> Would you please clarify that what do you mean by "set b=3D1 operation =
is on
> the way"?
>=20
> If "set b=3D1" is accepted by the leader, the client won't have to =
resend it
> on reconnect.
>=20
> Regards,
> Andor
>=20
>=20
> On Mon, Nov 13, 2017 at 5:01 AM, =E9=99=88=E5=AE=97=E5=BF=97 =
<baotiao@gmail.com <mailto:baotiao@gmail.com>> wrote:
>=20
>> I want to know in the following situation, how zookeeper promise =
client
>> FIFO order.
>>=20
>> the client sent three operation to server, set a =3D 1, set b =3D 1, =
set ready
>> =3D true.
>>=20
>> 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 =
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.
>>=20
>> the question is how zab promise client FIFO order?
>>=20
>> 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.
>>=20
>> is this the way the zab used to primise FIFO order?
>>=20
>> Thank you all
>>=20
>> --
>> ---
>> Blog: http://www.chenzongzhi.info
>> Twitter: https://twitter.com/baotiao <https://twitter.com/baotiao> =
<https://twitter.com/#%21/baotiao <https://twitter.com/#%21/baotiao>>
>> Git: https://github.com/baotiao <https://github.com/baotiao>

--Apple-Mail=_2B517248-8C66-465B-8FC3-DD300472E92B--