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=145231990 > On 14 Nov 2017, at 13:08, Andor Molnar <an...@cloudera.com> wrote: > > Oh, I see your problem now. > Abe is right, you can find find the best answer in the book and the short > answer is, yes, it only promises channel fifo order. > > Regards, > Andor > > > On Tue, Nov 14, 2017 at 4:04 AM, baotiao <baot...@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=145231990 >> >>> On 14 Nov 2017, at 08:12, Abraham Fine <af...@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=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, 陈宗志 <baot...@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 = 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/#%21/baotiao >>> >>>>> Git: https://github.com/baotiao >>>>> >> >>
