[
https://issues.apache.org/jira/browse/CAMEL-25911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on CAMEL-25911 started by shashank.
----------------------------------------
> camel-test-dst - stage 2: an internal TimeSource in camel-util for the core
> code that waits, times tasks or throttles
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-25911
> URL: https://issues.apache.org/jira/browse/CAMEL-25911
> Project: Camel
> Issue Type: Improvement
> Components: camel-core, camel-test
> Reporter: shashank
> Assignee: shashank
> Priority: Major
>
> Stage 2 of CAMEL-25738, as discussed on dev@ ("[DISCUSS] An internal time
> source in camel-util (for deterministic simulation tests)", +1 from Claus).
> camel-test-dst runs the real consumer code of a component under one seeded
> scheduler with virtual time. It controls Camel's thread pools through the
> existing {{ThreadPoolFactory}} SPI, but core reads the clock and sleeps
> through {{System}} and {{Thread.sleep}} directly, so today a world either has
> the core classes rewritten at load time or lives with real time and real
> sleeps in core (redelivery delays, shutdown waits, task back-offs,
> throttlers).
> *Proposal*
> * A small static, internal {{TimeSource}} in camel-util with
> {{currentTimeMillis()}}, {{nanoTime()}}, {{instant()}} and {{sleep(long)}}.
> The default provider delegates to {{System}} and {{Thread.sleep}}; a test
> harness can install another provider ({{install(Provider)}}, a volatile
> field). Static rather than per CamelContext, because {{StopWatch}} and
> {{MonotonicClock}} have no context.
> * Move only the about 30 core call sites that change behaviour:
> ** waits: {{RedeliveryPolicy.sleep}} and the sleep loop of
> {{RedeliveryErrorHandler}}, {{ForegroundTask}}, the wait loop of
> {{DefaultShutdownStrategy}}, {{DelayProcessorSupport}},
> {{MulticastProcessor}}, {{OptimisticLockRetryPolicy}},
> {{DefaultStartupConditionStrategy}};
> ** task timing: {{StopWatch}}, {{MonotonicClock}}, {{AbstractTask}},
> {{BackgroundTask}}, {{TimeBoundedBudget}}, {{BackOffTimerTask}},
> {{DefaultTimeoutMap}};
> ** throttling: {{TotalRequestsThrottler}}, {{ConcurrentRequestsThrottler}},
> {{SamplingThrottler}}, {{ThrottlingExceptionRoutePolicy}}.
> * Event timestamps, the debugger, the tracer, management and the consoles
> stay on {{System}}.
> * camel-test-dst installs its virtual clock as the provider, so the load-time
> rewriting is only needed for the component under test (and is loaded with
> {{-javaagent}} instead of a runtime attach).
> * Later: components use {{TimeSource}} when they are touched anyway; a
> forbidden-apis rule can keep new {{Thread.sleep}} / {{Instant.now()}} out of
> consumers.
> *Cost*: a JMH benchmark posted to the dev@ thread (JDK 21, AArch64, 3 forks)
> measured about 0.2 ns more per {{nanoTime()}} call and about 0.5 ns per
> {{StopWatch}} on one thread, nothing measurable for {{currentTimeMillis()}}
> and nothing measurable with 8 threads; a volatile field was not measurably
> slower than a plain one. For scale, the simplest direct -> log route takes
> about 410 ns per message.
> *Plan*: one pull request with {{TimeSource}} and its tests, the call sites
> above, and camel-test-dst using it; no behaviour change with the default
> provider. An existing world (for example camel-aws2-sqs) shows the core waits
> running in virtual time.
> _Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
