gnodet opened a new pull request, #25206: URL: https://github.com/apache/camel/pull/25206
_Claude Code on behalf of gnodet_ ## Summary `Delayer.delayValue` is a plain `long` field written by routing threads (in `calculateDelay()`) and read by JMX threads (via `ManagedDelayer.getDelay()` → `getDelayValue()`). This creates a JMM visibility gap: - On **32-bit JVMs**, reads of a `long` are non-atomic (JLS 17.7), so JMX could observe a torn value - On **all JVMs**, there is no happens-before guarantee, so stale reads are possible This was flagged during review of PR #24985 (CAMEL-24227 volatile sweep), which fixed the forward direction (`delay` Expression written by JMX, read by routing threads) but missed the reverse direction (`delayValue` written by routing threads, read by JMX). ### Fix Add `volatile` to the `delayValue` field. On x86 this compiles to the same `MOV` instruction as a plain load, so there is zero performance cost. No `AtomicLong` is needed because there are no read-modify-write operations — it's pure store/load. ## Test plan - [x] `DelayerTest`, `DelayerAsyncDelayedTest`, `DelayerPerRouteTest` pass - [x] `ManagedDelayerTest` (JMX MBean that reads `delayValue`) passes - [x] `camel-core-processor` module compiles and formats cleanly - [ ] Full CI 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude Opus 4.6 <[email protected]> -- 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]
