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)

Reply via email to