You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@kudu.apache.org by "Alexey Serbin (Jira)" <ji...@apache.org> on 2019/09/24 19:25:00 UTC

[jira] [Created] (KUDU-2955) kudu-master: separate RPC service queues for TSHeartbeat and other client-facing RPCs

Alexey Serbin created KUDU-2955:
-----------------------------------

             Summary: kudu-master: separate RPC service queues for TSHeartbeat and other 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


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)