zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From baotiao <baot...@gmail.com>
Subject Re: how zookeeper promise FIFO client order
Date Tue, 14 Nov 2017 03:04:34 GMT
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