zookeeper-user 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 Wed, 15 Nov 2017 08:01:46 GMT
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 <shralex@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 <baotiao@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 <andor@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 <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