On 24/09/2025 02:59, Christopher Schultz wrote:
On 9/22/25 11:55 AM, [email protected] wrote:

Thanks for the review. Comments in-line.

<snip/>

diff --git a/java/org/apache/coyote/AbstractProcessor.java b/java/org/ apache/coyote/AbstractProcessor.java
index df51a4ee87..a341735d19 100644
--- a/java/org/apache/coyote/AbstractProcessor.java
+++ b/java/org/apache/coyote/AbstractProcessor.java
@@ -1045,7 +1045,7 @@ public abstract class AbstractProcessor extends AbstractProcessorLight implement
          // information (e.g. client IP)
          setSocketWrapper(socketWrapper);
          // Set up the minimal request information
-        request.setStartTimeNanos(System.nanoTime());
+        request.markStartTime();
          // Set up the minimal response information
          response.setStatus(400);
          response.setError();

I think reasonable people can disagree about exactly where the start-of- request timestamp should be taken, but I think maybe it should be as close to the web application as possible.

Should we move the call to request.markStartTime to the end of this method?

In ms the difference is probably negligible but in ns, it might make a difference.

I take the opposite view. I think the request processing time should include as much of the Tomcat "overhead" as possible. For valid requests, the start time is the point where we read the first byte.

In this case the processing doesn't get as far as the first byte. If anything, the call to markStartTime() should be moved to the start of the method although I don't think that will make a significant difference.

<snip/>

+    @Deprecated
      public void setStartTimeNanos(long startTimeNanos) {
          this.startTimeNanos = startTimeNanos;
      }
+    public void markStartTime() {
+        startTimeNanos = System.nanoTime();
+    }

Should this call setStartTimeNanos(System.nanoTime) for backward compatibility?

I don't think so.

I'll go ahead and say it now since I won't be around to say "I told you so" later, but we're set up here for a year-2554 bug. :D

startTimeNanos is only used for duration, not absolute start time. I think I missed part of the back-port here and added the Instant to record the absolute start time in a later commit.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to