[
https://issues.apache.org/jira/browse/KUDU-2835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16852741#comment-16852741
]
Adar Dembo commented on KUDU-2835:
----------------------------------
I'm curious why you're trying to track timeouts server-side at all. Isn't it
easier to track them client-side?
# When an RPC times out, you'll intrinsically know to which task it belonged,
and to what job.
# Your tracking will capture timed out requests that never made it to Kudu at
all (i.e. requests that failed due to some fundamental networking issue).
> Add custom id in RpcHeader
> --------------------------
>
> Key: KUDU-2835
> URL: https://issues.apache.org/jira/browse/KUDU-2835
> Project: Kudu
> Issue Type: Improvement
> Reporter: Xu Yao
> Priority: Major
>
> In our production environment, there are many distributed jobs that send
> request to Kudu by KuduClient. However, if there are some RPC timeouts on the
> server, it is difficult to find the affected KuduClient based on the
> information of rpcz. Because there may be many KuduClients on each host.
> So we want to add extra information to RpcHeader to find out the problematic
> distributed tasks.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
