davsclaus opened a new pull request, #29386:
URL: https://github.com/apache/camel/pull/29386
## What
The CAMEL-26607 items for 4.24 (stage 2 of camel-chaos).
**More than one StepHook and SendHook.** camel-chaos acts on an integration
through the `StepHook` (before each step: delay or fail it) and the `SendHook`
(around each send: delay, fail or skip it). Both were one slot per
CamelContext: when another hook held the slot, chaos logged a WARN and did not
fire there. The dev tools have to run together.
- `ExtendedCamelContext` has `addStepHook/removeStepHook` and
`addSendHook/removeSendHook` in place of the setters, which came in 4.24 and
were never released, so there is no upgrade-guide entry.
- `getStepHook()` and `getSendHook()` still return one hook: the hook
itself, or a composite when there are several. A step still costs one null
check.
- `getStepHooks()` and `getSendHooks()` list the hooks in the order they are
asked, as `getStepListeners()` does.
- `CompositeStepHook` and `CompositeSendHook` (camel-support) sort the hooks
by `Ordered`:
- Step hooks are asked in order: the first that fails the step stops the
others, and the delays add up.
- Send hooks: the first `SKIP` wins, and a `SKIP` does not wait for a
delay another hook asked for, as with one hook. `afterSend` runs in reverse,
only on the hooks that were asked.
- camel-chaos takes `Ordered.LOWEST`, so it runs last, and the WARN is gone.
It never removes its hooks: they stay installed when the CamelContext stops and
starts again, as the step listeners do.
- The javadoc says a hook that only observes takes a low order, and one that
changes the outcome a high order. A tool that only observes should rather use
the `StepListener` of CAMEL-26688; these hooks are for the ones that act.
**A `duplicate` fault.** A send hook can answer `SendHook.SEND_TWICE`. After
the first send succeeds, a copy of the message is sent again. A stream body is
cached first, so it can be read twice. The copy is taken after the hooks ran,
so a corrupted message is sent twice the same way, as a real redelivery of the
same message would be. A failed first send is not repeated. The second reply
wins, and `afterSend` and the events run once. camel-chaos has a `duplicate`
fault at sends and a "duplicate delivery" recipe, to test idempotent consumers.
## Docs
The chaos page (the fault, the recipe), the hook javadoc, the security model
(the faults listed), and the exchange sanitizer design (the composable
`StepHook` it named as future work is this). The catalog copies of camel-chaos
are regenerated.
## Tests
- `CompositeHookTest` (camel-support): order, the first failure, the sum of
the delays, `SKIP`, `afterSend` in reverse, `SEND_TWICE`.
- `MultipleHooksTest`: two hooks of each kind on a route, and
`getStepHooks`/`getSendHooks` in order.
- `SendHelperTest`: the second send, sync and async.
- Duplicate: InOnly gives two messages, InOut gets the second reply, a
failing first send is not repeated, a stream body arrives twice, and an
`idempotentConsumer` drops the copy.
- The `StepHook` and `SendHook` tests, and the `StepListener` tests of
CAMEL-26688, use `addStepHook`.
- Locally: the hook, listener and idempotent tests of camel-core (111), the
composite tests (64), camel-management, and camel-chaos (671) pass.
JIRA: https://issues.apache.org/jira/browse/CAMEL-26607
_Claude Code on behalf of Claus Ibsen_
--
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]
