Description
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.
Attachments
Issue Links
- is related to
-
KUDU-3115 Improve scalability of Kudu masters
-
- Open
-