Add filter for measuring request response time

[Cavve]

Implemented a filter that measures how long each incoming HTTP request takes to process. The filter should record the start time before delegating to the next filter in the chain, then calculate the elapsed time once the response is ready. It should log the total duration in milliseconds together with the request method and path.

Closes #92

Summary by CodeRabbit

• New Features
  • Implemented request timing and performance tracking to monitor and log the duration of HTTP requests, including method and path information for better visibility into application performance.

[coderabbitai]

📝 Walkthrough

Walkthrough

A new timing filter has been added to measure HTTP request processing duration. The TimingFilter class records the start time, delegates to the filter chain, calculates elapsed time, and logs the request method, path, and duration in milliseconds.

Changes

Cohort / File(s)	Summary
Timing Filter Implementation src/main/java/org/juv25d/filter/TimingFilter.java, src/main/java/org/juv25d/App.java	Introduced new TimingFilter class that measures HTTP request processing duration by recording start time, delegating to filter chain, calculating elapsed time, and logging request method, path, and duration. Registered filter in application pipeline with priority 0.

Sequence Diagram

sequenceDiagram
    actor Client
    participant TimingFilter
    participant FilterChain
    participant Server
    
    Client->>TimingFilter: HTTP Request
    Note over TimingFilter: Record start time
    TimingFilter->>FilterChain: doFilter(request, response, chain)
    FilterChain->>Server: Process request
    Server-->>FilterChain: Response ready
    FilterChain-->>TimingFilter: Return
    Note over TimingFilter: Calculate elapsed time<br/>Log method, path, duration
    TimingFilter-->>Client: HTTP Response

Loading

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Poem

🐰 A filter swift as rabbit's feet,
Measures requests from start to beat,
With milliseconds tracked so neat,
Timing's now delightfully complete! ⏱️

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately summarizes the main change: adding a filter for measuring request response time, which matches the core functionality introduced in the PR.
Linked Issues check	✅ Passed	The PR fully implements all requirements from issue #92: records start time, delegates to next filter, calculates elapsed time, and logs duration with HTTP method and path.
Out of Scope Changes check	✅ Passed	All changes are directly aligned with the linked issue #92; the TimingFilter class and App.java modifications are solely focused on implementing the request timing measurement feature.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

• 📝 Generate docstrings (stacked PR)
• 📝 Generate docstrings (commit on current branch)

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch filter-measure-time

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[fmazmz]

good!

dont forget to link this PR to the issue also.

[jesperlarsson1910]

Looks like a smart and well implemented filter.

Two questions:
For best accuracy this should be the first filter, but that's something the filterchain should handle right?

Could this maybe be incorporate the LoggingFilter given that they do similar things allthough with different timing and outputs, like adding the system.out between the timestamp and dofilter. Or is it best to keep them seperate?

[kristinaxm]

You need to sign thiscommit: Added TimingFilter to measure request duration and log ms

Think its possible to do with git rebase, then in the editor you can change that commit to edit and then --amend -5 to sign that specific commit and rebase --continue and push --force, because the merging is blocked due to that specific commit :)

[kristinaxm]

Or you can squash all commits to one, or you can drop that specific commit and commit it again

[coderabbitai]

Actionable comments posted: 3

🧹 Nitpick comments (1)

src/main/java/org/juv25d/filter/TimingFilter.java (1)

20-20: Integer division silently drops sub-millisecond precision.

For fast paths (< 1 ms), (System.nanoTime() - start) / 1_000_000 always produces 0 ms, which is misleading. Consider using floating-point or logging in microseconds for finer resolution.

♻️ Proposed fix

-        long durationMs = (System.nanoTime() - start) / 1_000_000;
-        logger.info(req.method() + " " + req.path() + " took " + durationMs + " ms");
+        double durationMs = (System.nanoTime() - start) / 1_000_000.0;
+        logger.info(req.method() + " " + req.path() + " took " + String.format("%.3f", durationMs) + " ms");

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/main/java/org/juv25d/filter/TimingFilter.java` at line 20, The current
Duration calculation in TimingFilter uses integer division when computing
durationMs (long durationMs = (System.nanoTime() - start) / 1_000_000), which
drops sub-millisecond precision; change durationMs to a floating-point value
(e.g., double durationMs = (System.nanoTime() - start) / 1_000_000.0) or compute
and log microseconds instead, and update any logging/formatting that references
durationMs to accept the new type (look for the durationMs variable and its use
in TimingFilter).

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/main/java/org/juv25d/App.java`:
- Line 42: TimingFilter is being added after other filters so it runs last and
doesn't measure their latency; change the registration order or priority so
TimingFilter wraps the full request lifecycle: move the
pipeline.addGlobalFilter(new TimingFilter(), 0) call to execute before
registering SecurityHeadersFilter, RedirectFilter, IpFilter, and LoggingFilter,
or give TimingFilter a higher priority (e.g., a lower numeric value if smaller
means earlier) when calling pipeline.addGlobalFilter to ensure TimingFilter
executes first and captures end-to-end timing.

In `@src/main/java/org/juv25d/filter/TimingFilter.java`:
- Around line 16-21: In TimingFilter, ensure the timing and logger.info call
always runs by wrapping the chain.doFilter(req, res) call in a try-finally:
record start with the existing start variable, call chain.doFilter(req, res)
inside try, compute duration and call logger.info(req.method() + " " +
req.path() + " took " + durationMs + " ms") in finally so timing is logged even
when chain.doFilter throws, and rethrow the exception (do not swallow it).
- Line 21: The log entry in TimingFilter (logger.info using req.method(),
req.path(), durationMs) is vulnerable to log injection because req.path() may
contain CR/LF; sanitize the path before logging by removing or escaping CR and
LF characters (e.g., replace CR/LF with nothing or an escape) or introduce a
small helper like sanitizeLog(String) and use it when composing the message so
the final logger.info uses the sanitized path instead of raw req.path().

---

Nitpick comments:
In `@src/main/java/org/juv25d/filter/TimingFilter.java`:
- Line 20: The current Duration calculation in TimingFilter uses integer
division when computing durationMs (long durationMs = (System.nanoTime() -
start) / 1_000_000), which drops sub-millisecond precision; change durationMs to
a floating-point value (e.g., double durationMs = (System.nanoTime() - start) /
1_000_000.0) or compute and log microseconds instead, and update any
logging/formatting that references durationMs to accept the new type (look for
the durationMs variable and its use in TimingFilter).

[fmazmz]

@Cavve please merge ASAP so we dont get more conflicts and have to re-review :=)