Hi Alexander Atomix has done what I said client FIFO order. Both of us agree that client FIFO order is a nice feature, since there is lots of operations in zookeeper need to promise client FIFO order. And zookeeper uses lots of asynchronization operation, I have heard from my friends there is corner case that when zookeeper change leader, zookeeper can't promise client FIFO order. so I think zookeeper should provide a client FIFO order like Atomix. Anyway, the way used in Atomix is too simple, we can add some other strategy in it.
I have open a jira ticket https://issues.apache.org/jira/browse/ZOOKEEPER-2941 <https://issues.apache.org/jira/browse/ZOOKEEPER-2941> let's discuss in this ticket ---------------------------------------- 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 15 Nov 2017, at 00:55, Alexander Shraer <[email protected]> wrote: > > Hi, > > Specific implementations of Raft may guarantee client program order, but I > don't think that it directly follows from tcp order + state machine. > It matters whether commands are committed to the log according to program > order. For example, here's an implementation that seems > to be doing this: > http://atomix.io/copycat/docs/client-interaction/#preserving-program-order In > any case, this is probably not the right forum > for Raft questions :) > > I'm not sure we want to do command queueing on the leader like in the link > above or maybe just reset the client session if we're missing requests. In > any case, > perhaps this is worth a discussion on a JIRA. What do others think ? > Baotiao, would you like to open one ? > > Thanks, > Alex > > > On Tue, Nov 14, 2017 at 2:41 AM, baotiao <[email protected]> wrote: > >> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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, 陈宗志 <[email protected]> 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 >>>>>>> >>>> >>>> >> >>
