[
https://issues.apache.org/jira/browse/HADOOP-15768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16618964#comment-16618964
]
Steve Loughran commented on HADOOP-15768:
-----------------------------------------
note that the nanotime is only guaranteed to be monotonic in code running in a
single core: if the code is rescheduled onto a different core on the same CPU
die, some parts have different clocks; if it runs on a core in a different
socket there are no guarantees. So its only safe to use for calls where you
don't think things will be blocked.
But: it's a lower cost query.
I'd recommend that if the processing time is negative —which will only happen
on cross-core rescheduling—, its not added to the metrics. That way: the
metrics aren't tainted
> Do not use Time#now to calculate the rpc process time duration
> --------------------------------------------------------------
>
> Key: HADOOP-15768
> URL: https://issues.apache.org/jira/browse/HADOOP-15768
> Project: Hadoop Common
> Issue Type: Bug
> Affects Versions: 3.1.1
> Reporter: Yiqun Lin
> Assignee: Ryan Wu
> Priority: Minor
>
> For the rpc process time calculation, we are using a not-recommended way:
> Using {{Time#now}} to calculate for this.
> {code}
> // Invoke the protocol method
> long startTime = Time.now();
> int qTime = (int) (startTime-receivedTime);
> ....
> int processingTime = (int) (Time.now() - startTime);
> ...
> server.updateMetrics(detailedMetricsName, qTime, processingTime, false);
> {code}
> Actually we should use {{Time#monotonicNow()}} instead. This JIRA will fix
> these across RpcEngine impl classes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
