[
https://issues.apache.org/jira/browse/CAMEL-26456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18138160#comment-18138160
]
Claus Ibsen commented on CAMEL-26456:
-------------------------------------
The DST world for the chaos lifecycle rules is merged on main via
https://github.com/apache/camel/pull/29046 (4.24.0).
_Claude Code on behalf of davsclaus_
> 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
> Priority: Major
> Fix For: 4.24.0
>
>
> 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)
