[
https://issues.apache.org/jira/browse/KUDU-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16142345#comment-16142345
]
Adar Dembo commented on KUDU-683:
---------------------------------
bq. Adar Dembo do you think we still have a lot of tech debt here?
Yeah. I suppose it's not really specific to multi-master anymore; it's just
that the multi-master work from a few years ago exacerbated things.
The main issues are still the same ones as before: intermingling of RPC control
flow and "business logic", and the stream of callbacks is tough to follow.
> 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
>
> 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
(v6.4.14#64029)
