shashank created CAMEL-25911:
--------------------------------
Summary: 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
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)
