[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)
[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: - Code Review: https://gerrit.cloudera.org/c/12002/ > 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)
[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 ] Grant Henke updated KUDU-683: - Target Version/s: 1.8.0 (was: 1.5.0) > 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 >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)
