You are viewing a plain text version of this content. The canonical link for it is here.

Posted to issues@kudu.apache.org by "Andrew Wong (JIRA)" <ji...@apache.org> on 2019/01/03 05:23:00 UTC

[jira] [Updated] (KUDU-683) Clean up multi-master tech debt

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

Andrew Wong updated KUDU-683:
-----------------------------

91f104d conglomerated a bunch of client-to-master RPC logic for the C++ client, similar to what's described in the Jira.

> Clean up multi-master tech debt
> -------------------------------
>
>                 Key: KUDU-683
>                 URL: https://issues.apache.org/jira/browse/KUDU-683
>             Project: Kudu
>          Issue Type: Bug
>          Components: client
>    Affects Versions: M5
>            Reporter: Adar Dembo
>            Assignee: Andrew Wong
>            Priority: Major
>
> Multi-master support in the C++ client has introduced a fair amount of RPC-related tech debt. There's a lot of duplication in the handling of timeouts, retries, and error conditions. The various callbacks are also tricky to follow and error prone. Now that the code has settled and we understand what's painful about it, we're in a better position to fix it.
> Here's a high-level design idea: there should only be one RPC class that's responsible for RPC delivery end-to-end, including retries, leader master discovery, etc. Within that class there should be a single callback that's reused for every asynchronous function, and there should be a separate state machine that tracks the ongoing status of the RPC. Per-RPC specialization should be as minimal as possible, via templates on the PBs, callbacks, or, worst case, subclassing.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)