Mailing-List: contact user-help@zookeeper.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@zookeeper.apache.org
From: baotiao <baotiao@gmail.com>
Message-Id: <A750D3FD-D83A-47B1-AA8D-A0EBD9447C90@gmail.com>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_7B4A6E20-09EF-443A-BFFF-A5C2DE20BFC1"
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 11:04:34 +0800
In-Reply-To: <1510618325.2966293.1171459416.240F2D1D@webmail.messagingengine.com>
Cc: user@zookeeper.apache.org,
 afine@apache.org
To: dev@zookeeper.apache.org
References: <CAGbZs7g1Dt6QXZo1S0DLFrJ6X5SxvXXFR+j2OJeyksGBVyGe-Q@mail.gmail.com>
 <CAFBpvfsOVjTV3tz+TbFmxJRJwwS6L9qDemCzOGHij_iicuVoWQ@mail.gmail.com>
 <1510618325.2966293.1171459416.240F2D1D@webmail.messagingengine.com>
archived-at: Tue, 14 Nov 2017 03:04:52 -0000

--Apple-Mail=_7B4A6E20-09EF-443A-BFFF-A5C2DE20BFC1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hello Abraham

right, exactly.

my confusion is that the client FIFO order is for a client or only for a =
tcp connection
----------------------------------------
=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 14 Nov 2017, at 08:12, Abraham Fine <afine@apache.org> wrote:
>=20
> Hello-
>=20
> 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.
>=20
> Thanks,
> Abe
>=20
> On Mon, Nov 13, 2017, at 06:17, Andor Molnar wrote:
>> 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> 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/#%21/baotiao>
>>> Git: https://github.com/baotiao
>>>=20


--Apple-Mail=_7B4A6E20-09EF-443A-BFFF-A5C2DE20BFC1--