how zookeeper promise FIFO client order

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

how zookeeper promise FIFO client order

陈宗志
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
Reply | Threaded
Open this post in threaded view
|

Re: how zookeeper promise FIFO client order

Andor Molnar
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, 陈宗志 <[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: how zookeeper promise FIFO client order

Abraham Fine
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, 陈宗志 <[hidden email]> 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
> >
Reply | Threaded
Open this post in threaded view
|

Re: how zookeeper promise FIFO client order

陈宗志
In reply to this post by Andor Molnar
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 order.

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 <[hidden email]> 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, 陈宗志 <[hidden email] <mailto:[hidden email]>> 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/baotiao> <https://twitter.com/#%21/baotiao <https://twitter.com/#%21/baotiao>>
>> Git: https://github.com/baotiao <https://github.com/baotiao>
Reply | Threaded
Open this post in threaded view
|

Re: how zookeeper promise FIFO client order

陈宗志
In reply to this post by Abraham Fine
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 <[hidden email]> 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, 陈宗志 <[hidden email]> 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
>>>

Reply | Threaded
Open this post in threaded view
|

Re: how zookeeper promise FIFO client order

Andor Molnar
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 <[hidden email]> 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 <[hidden email]> 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, 陈宗志 <[hidden email]> 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
> >>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: how zookeeper promise FIFO client order

陈宗志
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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, 陈宗志 <[hidden email]> 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
>>>>>
>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: how zookeeper promise FIFO client order

Alexander Shraer-2
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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, 陈宗志 <[hidden email]> 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
> >>>>>
> >>
> >>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: how zookeeper promise FIFO client order

陈宗志
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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, 陈宗志 <[hidden email]> 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
>>>>>>>
>>>>
>>>>
>>
>>