You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@zookeeper.apache.org by 陈宗志 <ba...@gmail.com> on 2017/11/13 04:01:25 UTC
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
Re: how zookeeper promise FIFO client order
Posted by baotiao <ba...@gmail.com>.
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 <an...@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 <ma...@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/baotiao> <https://twitter.com/#%21/baotiao <https://twitter.com/#%21/baotiao>>
>> Git: https://github.com/baotiao <https://github.com/baotiao>
Re: how zookeeper promise FIFO client order
Posted by baotiao <ba...@gmail.com>.
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 <sh...@gmail.com> 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 <ba...@gmail.com> 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 <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 <ba...@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, 陈宗志 <ba...@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
>>>>>>>
>>>>
>>>>
>>
>>
Re: how zookeeper promise FIFO client order
Posted by baotiao <ba...@gmail.com>.
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 <sh...@gmail.com> 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 <ba...@gmail.com> 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 <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 <ba...@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, 陈宗志 <ba...@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
>>>>>>>
>>>>
>>>>
>>
>>
Re: how zookeeper promise FIFO client order
Posted by Alexander Shraer <sh...@gmail.com>.
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 <ba...@gmail.com> 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 <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 <ba...@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, 陈宗志 <ba...@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
> >>>>>
> >>
> >>
>
>
Re: how zookeeper promise FIFO client order
Posted by Alexander Shraer <sh...@gmail.com>.
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 <ba...@gmail.com> 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 <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 <ba...@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, 陈宗志 <ba...@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
> >>>>>
> >>
> >>
>
>
Re: how zookeeper promise FIFO client order
Posted by baotiao <ba...@gmail.com>.
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 <ba...@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, 陈宗志 <ba...@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
>>>>>
>>
>>
Re: how zookeeper promise FIFO client order
Posted by baotiao <ba...@gmail.com>.
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 <ba...@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, 陈宗志 <ba...@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
>>>>>
>>
>>
Re: how zookeeper promise FIFO client order
Posted by Andor Molnar <an...@cloudera.com>.
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 <ba...@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, 陈宗志 <ba...@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
> >>>
>
>
Re: how zookeeper promise FIFO client order
Posted by Andor Molnar <an...@cloudera.com>.
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 <ba...@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, 陈宗志 <ba...@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
> >>>
>
>
Re: how zookeeper promise FIFO client order
Posted by baotiao <ba...@gmail.com>.
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, 陈宗志 <ba...@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
>>>
Re: how zookeeper promise FIFO client order
Posted by baotiao <ba...@gmail.com>.
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, 陈宗志 <ba...@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
>>>
Re: how zookeeper promise FIFO client order
Posted by Abraham Fine <af...@apache.org>.
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, 陈宗志 <ba...@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
> >
Re: how zookeeper promise FIFO client order
Posted by Abraham Fine <af...@apache.org>.
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, 陈宗志 <ba...@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
> >
Re: how zookeeper promise FIFO client order
Posted by Andor Molnar <an...@cloudera.com>.
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, 陈宗志 <ba...@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
>