Uploaded image for project: 'Kudu'
  1. Kudu
  2. KUDU-2955

kudu-master: separate RPC service queues for TSHeartbeat from client-facing RPCs

    XMLWordPrintableJSON

    Details

    • Type: Improvement
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: master, rpc
    • Labels:
      None

      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

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                aserbin Alexey Serbin
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated: