shashank created CAMEL-26456:
--------------------------------
Summary: camel-chaos - route lifecycle faults (stall, lifecycle)
and a DST world that runs chaos rules in virtual time
Key: CAMEL-26456
URL: https://issues.apache.org/jira/browse/CAMEL-26456
Project: Camel
Issue Type: Improvement
Components: camel-core
Reporter: shashank
Assignee: shashank
Last stage of CAMEL-26330 (design/chaos.adoc, steps "Route lifecycle faults"
and "A DST world that runs chaos rules in virtual time" of "Order of work").
The rule syntax of the design already has {{stall duration=<time>}} and
{{lifecycle action=suspend|stop|remove duration=<time>}} for a {{route=}}
target, and so has the {{camel.chaos.rules}} example; today the parser rejects
them as "not supported yet". And the design says the same rules run in virtual
time inside a {{camel-test-dst}} world, which nothing shows or tests yet.
*Proposal*
* {{route=<id> stall duration=<time>}} (short for {{lifecycle action=suspend}})
and {{route=<id> lifecycle action=suspend|stop|remove duration=<time>}}: the
rule acts once on the route when it is added (a rule of {{camel.chaos.rules}}
when the context has started), and brings the route back after the duration:
resume, start, or add the same route definition back. The action and the
comeback are tasks of a scheduled executor of the {{ExecutorServiceManager}}
(created when the first such rule acts), through the route controller of the
context and {{CamelContext.removeRoute}}.
* Validation by the parser of the rules: the route id (not a pattern) must
exist when the rule is added (for {{camel.chaos.rules}}: once the context
created its routes, else the context does not start); {{at}}, {{rate}} and
{{until}} are rejected (the fault acts once); the duration is at most
{{camel.chaos.maxDuration}}; {{action=remove}} needs a route from the route
model, whose definition can be added back; a route created from a route
template or a kamelet is rejected for it (removing the route closes the local
beans of its template). An expectation ({{expect=}}, {{within=}}) can be added.
* Chaos only brings back what it took down: a route that is not started when
the rule acts is left alone ("skipped"); at the comeback, a route someone else
changed meanwhile (its status, removed, or a new route with the same id from a
reload) is left as it is ("left"). Removing, changing or clearing the rule
while the route is down brings it back at once; when the context stops, a
pending comeback is cancelled and the executor shut down ("cancelled"). With
the supervising route controller, the stop is a manual operation for the
controller (it does not restart the route while it is down), and the comeback
starts the route through it.
* The report keeps what each lifecycle rule did: the action, the state
({{pending}}, {{down}}, {{back}}, {{skipped}}, {{left}}, {{failed}},
{{cancelled}}), the times after the rule was added at which the route went down
and came back, and the reason when it did not go as planned; in the text and in
the JSON ({{lifecycle}} object of the rule).
* Fail closed as before: nothing of chaos is installed with profile {{prod}},
so these rules are ignored there.
* A deterministic simulation test in the tests of camel-chaos
({{ChaosLifecycleDstTest}}): a route consumes a fake queue (a scheduled poll
consumer) and calls a downstream system asynchronously, under a seeded
lifecycle rule (up to 10 minutes, added while an exchange is in flight) and a
{{step=}} rule that fails the downstream call at a seeded rate. A 10 minute
stall takes milliseconds; the same seed gives the same report again, times
included; and the test checks from the report that no message is lost (an
expectation), that the redeliveries add up to the step faults, and that the
route was down for exactly the duration and took no message meanwhile.
camel-chaos keeps no dependency on camel-test-dst outside its tests.
* Two pull requests, one per step of the design: the lifecycle faults, then the
DST world on top of them.
* Docs: the chaos page (faults table, "Route lifecycle faults", "Time and the
seed") with its catalog copy, and design/chaos.adoc (the two steps done).
_Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)