[
https://issues.apache.org/jira/browse/KUDU-2955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Serbin updated KUDU-2955:
--------------------------------
Summary: kudu-master: separate RPC service queues for TSHeartbeat from
client-facing RPCs (was: kudu-master: separate RPC service queues for
TSHeartbeat from other client-facing RPCs)
> kudu-master: separate RPC service queues for TSHeartbeat from client-facing
> RPCs
> --------------------------------------------------------------------------------
>
> Key: KUDU-2955
> URL: https://issues.apache.org/jira/browse/KUDU-2955
> Project: Kudu
> Issue Type: Improvement
> Components: master, rpc
> Reporter: Alexey Serbin
> Priority: Minor
>
> As of now, all client-related RPCs like {{ConnectToMaster}},
> {{GetTabletLocations}}, {{GetTableLocations}}, {{GetTableSchema}}, etc.,
> tserver-related RPC {{TSHeartbeat}}, and other administrative RPCs are all
> put into the same RPC service queue upon arrival. In some cases of
> congestion (e.g., full tablet reports from all tablet servers in a cluster
> upon the change in the master leadership) and aggravating factors such as
> slow master's WAL, that might lead to dropping requests sent from Kudu
> clients to master, even if the inflow of client requests isn't high and the
> client request might be served in parallel with processing {{TSHeartbeat}}
> sent from tablet servers.
> It would be nice to put all {{TSHeartbeat}} requests and other administrative
> requests into one service queue, and all the client-originated requests into
> another. That way spikes of RPC inflow from clients would not affect
> internal cluster bookkeeping and vice versa.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
