allthingssecurity opened a new pull request, #29046:
URL: https://github.com/apache/camel/pull/29046
# Description
CAMEL-26456 (related to CAMEL-26330 and CAMEL-26418): **a DST world that
runs chaos rules in virtual time**, as an
example and a regression test: step 8 of "Order of work" in
`design/chaos.adoc`. It builds on the route lifecycle
faults of #28812 (step 6), now merged.
`ChaosLifecycleDstTest` (package `org.apache.camel.component.chaos.dst`, in
the tests of camel-chaos): a route consumes
a fake queue and calls a downstream system asynchronously, under two rules
added through the public `ChaosManager` API:
- `step=downstream error rate=0.1|0.3`, from the start, which the error
handler redelivers (1, 2 or 5 redeliveries,
without a delay: see below),
- and a lifecycle rule (`stall`, or `lifecycle` with `suspend`, `stop` or
`remove`, for 1, 5 or 10 minutes), added by
an operator at a seeded time once an exchange is in flight (so the suspend
or stop waits for it in the shutdown
strategy), with an expectation that the route completes every message it
has not completed yet.
The world sets `camel.chaos.seed` to the seed of the run, as the design
says, and the seed picks the rule, its time, the
duration, the rate, the redeliveries and the messages: a burst before the
rule, the others after, one of them halfway
through the time the route is down. The checks:
1. no message is lost: the expectation is met, the verdict is PASS and final
(report);
2. the route completed every message once (report);
3. the redeliveries are the step faults that did not exhaust the error
handler (`redeliveries == fired - failed`), and
each failed exchange went back to the queue (report and fake);
4. the route was down for exactly the duration (virtual), and is back
(report);
5. no message was delivered while the route was down, and the one published
then only after it came back (fake);
6. every message deleted once, the queue drained (fake);
7. an exchange was in flight when the rule was added (the world); the route
is started at the end (route
controller).
Plus: the same seed gives the same report again, times included, and the
same trace hash (3 seeds, twice each in one
JVM); and a 10 minute stall takes milliseconds (10 minutes of virtual time;
the test allows 30 s of real time for a busy
CI machine, it takes well under a second here).
## Why this world
The thing under test is chaos with the route lifecycle of camel-core, not a
component, so the simplest honest world is
a route over a queue fake inside the tests of camel-chaos. The fake
(`FakeQueue`) keeps a message until the route
completes it, as a broker with client acknowledgement does, and its consumer
is a real `ScheduledPollConsumer` (the base
of the file, FTP and SQS consumers), so it is suspended, stopped and started
as theirs are. The SQS world would add
camel-aws2-sqs and the AWS SDK to the tests of camel-chaos for no extra
coverage of chaos. The downstream call is
`DstCamel.asyncStep`, as the one-stack model of test-dst.adoc asks for a
route that is suspended or stopped while an
exchange is in a downstream call. camel-chaos reads the clock and sleeps
only through `TimeSource`, so the escape scan of
its package finds 0 call sites and the seeds run in strict mode;
`DefaultShutdownStrategy`, `StopWatch` and
`org.apache.camel.support.task` are rewritten (`alsoRewrite`), as in the
Kafka share world, so the wait of a route stop
for its exchanges in flight runs the loop.
- The redeliveries have no delay. With a delay, the redelivery sleeps on the
thread of the exchange: in the one-stack
model of test-dst.adoc that exchange is below the route stop on the stack
and cannot finish, so the stop waited until
its timeout (seen in the first version of this world, once the rule was
added with an exchange in flight). With
`asyncDelayedRedelivery` the delay ran on an `ErrorHandlerRedeliveryTask`
thread outside the harness, which strict
mode fails. The error handler's pool escaping although `DstCamel` installs
the `DstThreadPoolFactory` may be a gap
of camel-test-dst; I can look at it in a follow-up.
- The agent is loaded with `-javaagent` (#28782), wired in the pom as in the
other modules with DST tests.
camel-test-dst is a test dependency only; the main code of camel-chaos
does not depend on it.
- Not a `@DstWorld` (#28787): the catalog lists the worlds of a component
under its scheme in the
component JSON, and camel-chaos is an "other" module with no component. I
can open a follow-up JIRA so that
`@DstWorld` can describe the worlds of other modules too.
- The test log of camel-chaos is now a size-capped rolling file (50 MB, one
backup), as for the other modules with DST
worlds: 5000 seeds write about 40 MB.
## Docs
The chaos page ("Time and the seed": the test as an example) with its
catalog copy; `design/chaos.adoc` marks step 8
done.
## Tests
`ChaosLifecycleDstTest`: 200 seeds by default (about 3 s), the replay test
and the 10 minute stall; run 20 times in its
own JVM, all passed, and once with 5000 seeds (`-Ddst.seeds=5000`), 0
failing. The camel-chaos module passes (505
tests). Negative controls on the world (on this version of it): a comeback
that never comes or comes 1 ms early, a suspend or a stop that does nothing,
and the report without `lifecycle` each make the world fail.
_Claude Code on behalf of allthingssecurity_
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
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]
