[
https://issues.apache.org/jira/browse/KUDU-1707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15584384#comment-15584384
]
Todd Lipcon commented on KUDU-1707:
-----------------------------------
One potential issue here is that we currently do the RPC parameter
deserializatoin on the handler thread, but to implement this we'd have to do it
on the reactor. This might be a little slower since the handler thread won't
have the deserialized request in its cache when it is time to run. Also, the
request is currently deallocated on the handler thread, so it will hurt
tcmalloc thread cache affinity. We should benchmark carefully to make sure we
don't regress other workloads with this change.
> Add hook to handle RPCs prior to queueing or rejection
> ------------------------------------------------------
>
> Key: KUDU-1707
> URL: https://issues.apache.org/jira/browse/KUDU-1707
> Project: Kudu
> Issue Type: Bug
> Components: rpc
> Affects Versions: 1.0.1
> Reporter: Todd Lipcon
> Assignee: Todd Lipcon
>
> When the Kudu RPC handlers are all busy, RPCs are rejected and it's up to the
> client to back-off and retry. This is usually a good idea, but is somewhat
> silly when the RPCs themselves are extremely lightweight. It can even be
> problematic when the RPC is responsible for updating liveness or detecting
> failures, as in cases like:
> - empty consensus updates which just need to update the Raft failure detector
> - the 'Ping' request that ksck uses to determine which tservers are online
> - the Scanner Keepalive call which just needs to keep a scanner open
> For these cases, it would be preferable to allow the RPC to be handled even
> if it would otherwise be rejected. For the consensus heartbeat example in
> particular, this handling would substantially reduce election storms when
> under high load.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
