zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From baotiao <baot...@gmail.com>
Subject Re: how zookeeper promise FIFO client order
Date Tue, 14 Nov 2017 02:59:32 GMT
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 = 1
2. set b = 1
3. set ready = true

these three operations are sending in pipeline, the first operation set a = 1 is process ok,
and the second operation set b = 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

Thank you 
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=145231990

> On 13 Nov 2017, at 22:17, Andor Molnar <andor@cloudera.com> 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=1 operation is on
> the way"?
> If "set b=1" 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, 陈宗志 <baotiao@gmail.com <mailto:baotiao@gmail.com>>
>> I want to know in the following situation, how zookeeper promise client
>> FIFO order.
>> the client sent three operation to server, set a = 1, set b = 1, set ready
>> = true.
>> is it possible to this situation that the set a = 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 = 1 operation
>> is on the way. then the client will use the new tcp connection to sent set
>> ready = true operation. so the set a = 1 is operated, set b = 1 is not and
>> set ready = 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 = 1, set ready = 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/baotiao> <https://twitter.com/#%21/baotiao
>> Git: https://github.com/baotiao <https://github.com/baotiao>

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message