zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andor Molnar <an...@cloudera.com>
Subject Re: how zookeeper promise FIFO client order
Date Tue, 14 Nov 2017 05:08:00 GMT
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 <baotiao@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 <afine@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, 陈宗志 <baotiao@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
> >>>
>
>

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