You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@kudu.apache.org by "Mike Percy (JIRA)" <ji...@apache.org> on 2016/02/26 12:49:18 UTC

[jira] [Updated] (KUDU-488) Implement queue synchronization by making peers refuse messages

     [ https://issues.apache.org/jira/browse/KUDU-488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mike Percy updated KUDU-488:
----------------------------
    Parent: KUDU-433

> Implement queue synchronization by making peers refuse messages
> ---------------------------------------------------------------
>
>                 Key: KUDU-488
>                 URL: https://issues.apache.org/jira/browse/KUDU-488
>             Project: Kudu
>          Issue Type: Sub-task
>          Components: consensus, tserver
>    Affects Versions: M4
>            Reporter: David Alves
>            Assignee: David Alves
>            Priority: Critical
>   Original Estimate: 16h
>  Remaining Estimate: 16h
>
> Currently we're going to great lengths to initialize the state of replicas (followers/learners) in the leaders replication queue. This is problematic, error prone, but more importantly there are a few situations where we can't know the state of the replica at all.
> Now that we have consensus-internal status messages we can use those to make peers refuse messages from the leader outright when they do not immediately follow their last known message.
> This is similar to the raft approach and only requires that the leader send a 'preceedingId' that the replica will try to match to it's last known message and act accordingly, i.e. by accepting or refusing the message. Should the replica refuse the message the leader can then adjust the watermark accordingly and send the correct messages.
> While simple from a consensus perspective this requires op abort at the tablet level.



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