RongtongJin commented on code in PR #10514:
URL: https://github.com/apache/rocketmq/pull/10514#discussion_r3563568160
##########
remoting/src/main/java/org/apache/rocketmq/remoting/protocol/RemotingCommand.java:
##########
@@ -635,12 +658,25 @@ public void setSerializeTypeCurrentRPC(SerializeType
serializeTypeCurrentRPC) {
this.serializeTypeCurrentRPC = serializeTypeCurrentRPC;
}
- public Stopwatch getProcessTimer() {
- return processTimer;
+ public long processTimerElapsedMs() {
+ if (processTimerNanos == 0) {
+ return 0;
+ }
+ return (System.nanoTime() - processTimerNanos) / 1_000_000;
+ }
+
+ @Deprecated
+ public com.google.common.base.Stopwatch getProcessTimer() {
+ return com.google.common.base.Stopwatch.createStarted();
+ }
+
+ @Deprecated
+ public void setProcessTimer(com.google.common.base.Stopwatch processTimer)
{
+ this.processTimerNanos =
processTimer.elapsed(java.util.concurrent.TimeUnit.NANOSECONDS);
Review Comment:
This compatibility adapter stores an elapsed duration in
`processTimerNanos`, but `processTimerElapsedMs()` treats that field as a
`System.nanoTime()` start timestamp. If any downstream code still calls the
deprecated `setProcessTimer(Stopwatch)` and later records latency through
`processTimerElapsedMs()`, it will report roughly JVM-uptime latency instead of
the request duration. Please either translate the elapsed value back to a
nanoTime origin, e.g. `System.nanoTime() - processTimer.elapsed(NANOSECONDS)`,
or make the deprecated adapter explicitly unsupported.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
