[
https://issues.apache.org/jira/browse/CAMEL-24927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-24927.
---------------------------------
Fix Version/s: 4.23.0
Resolution: Fixed
The fix is merged on main, so it is in Camel 4.23.0:
* 668c9299d846 CAMEL-24927: camel-core - Sample EIP should let the first
exchange through whatever the value of System.nanoTime() is
* 95f445b47237 CAMEL-24927: camel-spring-xml - Add the long period route to the
Spring sampling throttler test
Resolving, as the ticket was not updated when the PR was merged.
_Claude Code on behalf of Claus Ibsen_
> Sample EIP drops every message until the machine's uptime exceeds the sample
> period
> -----------------------------------------------------------------------------------
>
> Key: CAMEL-24927
> URL: https://issues.apache.org/jira/browse/CAMEL-24927
> Project: Camel
> Issue Type: Bug
> Components: camel-core
> Reporter: shashank
> Priority: Minor
> Fix For: 4.23.0
>
>
> The sample EIP is documented to select a single message in a given time
> period, so the first message should always pass. With a long sample period it
> drops everything for a while:
> {code:java}
> from("direct:start").sample(Duration.ofHours(24)).to("mock:result");
> {code}
> On a machine that was started less than 24 hours ago, no message reaches
> {{mock:result}} at all until the machine has been up for 24 hours. Measured
> on a machine that had been up for about 10 minutes ({{System.nanoTime()}} =
> 634906 ms), sending 5 messages to a fresh route:
> {noformat}
> sample(PT1S): 1 passed (expected 1)
> sample(PT5M17.453S): 1 passed (expected 1)
> sample(PT1H10M34.906S): 0 passed (expected 1)
> sample(PT8760H): 0 passed (expected 1)
> {noformat}
> On a JVM where {{System.nanoTime()}} has a negative origin (allowed by its
> javadoc), even the default 1 second period drops the first messages.
> Cause: {{SamplingThrottler}} measures time with {{System.nanoTime()}} (since
> CAMEL-20267, which moved away from {{System.currentTimeMillis()}}), but
> {{timeOfLastExchange}} still starts at {{0}}, and an exchange passes when
> {{now >= timeOfLastExchange + periodInMillis}}. With {{currentTimeMillis}}
> the first comparison always passed; with {{nanoTime}}, whose origin is
> arbitrary (on Linux and macOS about the time since boot), it only passes once
> {{nanoTime}} exceeds the period.
> Proposed fix: remember whether an exchange has been sampled yet, and always
> let the first one through.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
