You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bookkeeper.apache.org by "Sijie Guo (JIRA)" <ji...@apache.org> on 2014/12/04 20:05:12 UTC

[jira] [Commented] (BOOKKEEPER-799) Distribution schedule coverage sets don't take gaps in response lists into account when writequorum > ackquorum

    [ https://issues.apache.org/jira/browse/BOOKKEEPER-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14234487#comment-14234487 ] 

Sijie Guo commented on BOOKKEEPER-799:
--------------------------------------

the patch lgtm +1

> Distribution schedule coverage sets don't take gaps in response lists into account when writequorum > ackquorum
> ---------------------------------------------------------------------------------------------------------------
>
>                 Key: BOOKKEEPER-799
>                 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-799
>             Project: Bookkeeper
>          Issue Type: Bug
>            Reporter: Ivan Kelly
>            Assignee: Ivan Kelly
>            Priority: Blocker
>             Fix For: 4.4.0, 4.3.1, 4.2.4
>
>         Attachments: 0001-BOOKKEEPER-799-Distribution-schedule-coverage-sets-d.patch
>
>
> The algorithm now be used to check if all quorums are being covered when sending a read lac or fencing message is broken when writeQuorum >= ackQuorum.
> The purpose of the algorithm is to tell us when we have heard a response from enough nodes, that an ack quorum could not possibly have been formed without at least one of the nodes that we have heard responses from.
> The current algorithm works when writeQuorum == ackQuorum, as we consider all quorums covered if the first |ackQuorum| nodes in the writeQuorum are covered. However, this doesn't work in the case that it's the middle node in the quorum that we have heard.
> Take the example, e:4, w:3, a:2, and we've heard from node 0, and node 2. In this case, it is possible for the write quorum, 1,2,3 to get an ack quorum if 1 and 3 response. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)