ammachado opened a new pull request, #28819: URL: https://github.com/apache/camel/pull/28819
# Description [CAMEL-26475](https://issues.apache.org/jira/browse/CAMEL-26475), item (c) of the JMX section of [CAMEL-25132](https://issues.apache.org/jira/browse/CAMEL-25132). **This is a draft so that the tradeoff can be decided first: the gain is real but small on routes that do real work, and it needs an API addition and a field on every exchange. Declining it is a reasonable outcome.** With the default statistics level, each node read `nanoTime` twice. Removing the `StopWatch` allocation gave no measurable gain, so the cost is the clock reads: | variant, 1 thread | ops/s | |---|---| | current | about 545k | | no `nanoTime` | about 690k | | no `nanoTime`, no `StopWatch` | about 695k | A node now starts at the end time of the node before it, which `AbstractExchange` keeps through two new `ExchangeExtension` methods. `StopWatch` gets a constructor and a `taken` overload that take a known time. ## The tradeoff Gain, 10 node route that does nothing, default statistics level, JDK 21 Linux arm64 in a container with 9 CPUs, a new JVM per run, 4 rounds alternating. Not JMH. | threads | before, ops/s | after, ops/s | |---|---|---| | 1 | 531k to 540k | 605k to 633k (about +14%) | | 8 | 1.29M to 1.59M | 1.21M to 1.71M (no clear change, noisy) | That is about 230 ns per exchange on this route. The saving per exchange is fixed, so it depends on the route: with a 1 ms call it is about 0.02%. Costs: - **A `long` on every exchange**, also without JMX. It should add 8 B, going by the similar field in CAMEL-26426; this was not measured here. - **Two methods on `ExchangeExtension`** in `camel-api`, used only by `camel-management`. They are documented as internal. - **Reported times shift slightly:** framework time between two nodes now counts for the next node. This is small, but I did not measure it, and there is no upgrade guide entry for it. ## When the time is not reused A stale time would report something that ran outside the node, which is far worse than a slow clock read, so: - **A route always reads the clock**, as the same `Exchange` can be sent again at any later time. Its first node reuses that read. - **A failed node clears the time**, as an error handler can wait or run other things. With redelivery enabled, the instrumentation runs inside the error handler (`DefaultChannel`). - **A node without statistics clears the time**, such as with `onlyRegisterProcessorWithCustomId` or statistics disabled at runtime, or the next node would count its time. - **A copy does not get the time**, as a split or multicast item runs later, possibly in another thread. The clock goes through `TimeSource`, so deterministic simulation tests keep virtual time. Those tests were not run. Alternatives not used: sampling changes what the statistics mean, and a `ThreadLocal` keeps the last exchange and its body alive on each thread. ## Tests 7 new tests in `DefaultInstrumentationProcessorTimingTest` with a fake `TimeSource`, and 2 in `StopWatchTest`. The test that counts clock reads failed before the change. The other 6 protect the rules above, and old code passes them as it never reuses a time, so I removed each rule in turn: each removal failed exactly the tests for that rule. Verified, full module suites: `camel-util` 327 tests, `camel-support` 145, `camel-management` 594 (1 skipped), `camel-core` 8672 (44 skipped, not reviewed one by one), 0 failures. Component modules were not run. # Target - [x] I checked that the commit is targeting the correct branch (Camel 4 uses the `main` branch) # Tracking - [x] If this is a large change, bug fix, or code improvement, I checked there is a [JIRA issue](https://issues.apache.org/jira/browse/CAMEL) filed for the change (usually before you start working on it). # Apache Camel coding standards and style - [x] I checked that each commit in the pull request has a meaningful subject line and body. - [ ] I have run `mvn clean install -DskipTests` locally from root folder and I have committed all auto-generated changes. Not run from the root folder: I ran `mvn install -Dquickly` on the changed core modules, and `git status` showed only the changed files afterwards. # AI-assisted contributions - [x] If this PR includes AI-generated code, commits have proper co-authorship attribution (e.g., `Co-authored-by` trailers) and the PR description identifies the AI tool used. 🤖 Generated with [Claude Code](https://claude.com/claude-code) on behalf of Adriano Machado (@ammachado) _This was generated by an AI agent and may contain inaccuracies. Please verify before relying on it._ -- 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]
