This is an automated email from the ASF dual-hosted git repository. davsclaus pushed a commit to branch quick-fix/exchange-pattern-docs in repository https://gitbox.apache.org/repos/asf/camel.git
commit 82276e7ab91894d09b34c37a58f9b618aab0d74a Author: Claus Ibsen <[email protected]> AuthorDate: Wed Jul 22 19:12:39 2026 +0200 chore: Improve exchange pattern documentation to clarify behavior Co-Authored-By: Claude Opus 4.6 <[email protected]> Signed-off-by: Claus Ibsen <[email protected]> --- .../docs/modules/eips/pages/event-message.adoc | 18 ++++++++++++++ .../docs/modules/eips/pages/requestReply-eip.adoc | 16 +++++++++++++ .../modules/ROOT/pages/exchange-pattern.adoc | 28 ++++++++++++++++++++-- 3 files changed, 60 insertions(+), 2 deletions(-) diff --git a/core/camel-core-engine/src/main/docs/modules/eips/pages/event-message.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/event-message.adoc index b5a1acba8296..61a5a4a9fef6 100644 --- a/core/camel-core-engine/src/main/docs/modules/eips/pages/event-message.adoc +++ b/core/camel-core-engine/src/main/docs/modules/eips/pages/event-message.adoc @@ -77,6 +77,24 @@ YAML:: ---- ==== +== How It Works + +The `InOnly` exchange pattern is a contract between the route and the component endpoint. +It tells the producer component that the caller does *not* expect a reply (fire-and-forget). + +The exchange pattern does *not* affect how EIPs and processors work within the route. +Processors such as `setBody`, `transform`, `process`, and `bean` always operate on the +current message regardless of the exchange pattern. The pattern only matters when the exchange +reaches a producer endpoint that acts on it. + +Whether a component acts on the pattern depends on the component. +Asynchronous components such as xref:ROOT:jms-component.adoc[JMS] and +xref:ROOT:seda-component.adoc[SEDA] use `InOnly` to dispatch the message and continue +without waiting for a reply. Synchronous components such as +xref:ROOT:direct-component.adoc[Direct] always process in the same thread and call stack, +so the pattern has no practical effect on the dispatch behavior — the caller still waits for +the called route to complete. + == Using `setExchangePattern` EIP You can specify the diff --git a/core/camel-core-engine/src/main/docs/modules/eips/pages/requestReply-eip.adoc b/core/camel-core-engine/src/main/docs/modules/eips/pages/requestReply-eip.adoc index f5563546a58b..6c9f1d67f0a4 100644 --- a/core/camel-core-engine/src/main/docs/modules/eips/pages/requestReply-eip.adoc +++ b/core/camel-core-engine/src/main/docs/modules/eips/pages/requestReply-eip.adoc @@ -80,6 +80,22 @@ YAML:: ---- ==== +== How It Works + +The `InOut` exchange pattern is a contract between the route and the component endpoint. +It tells the producer component that the caller expects a reply message. + +The exchange pattern does *not* affect how EIPs and processors work within the route. +Processors such as `setBody`, `transform`, `process`, and `bean` always operate on the +current message regardless of the exchange pattern. The pattern only matters when the exchange +reaches a producer endpoint that acts on it. + +Whether a component acts on the pattern depends on the component. +Asynchronous components such as xref:ROOT:jms-component.adoc[JMS] use `InOut` to switch +to request/reply messaging (e.g., setting `JMSReplyTo` and waiting for a response). +Synchronous components such as xref:ROOT:direct-component.adoc[Direct] always process +in the same thread and call stack, so the pattern has no practical effect on the dispatch behavior. + == Using setExchangePattern EIP You can specify the diff --git a/docs/user-manual/modules/ROOT/pages/exchange-pattern.adoc b/docs/user-manual/modules/ROOT/pages/exchange-pattern.adoc index a3e232504e98..856ff5e755cc 100644 --- a/docs/user-manual/modules/ROOT/pages/exchange-pattern.adoc +++ b/docs/user-manual/modules/ROOT/pages/exchange-pattern.adoc @@ -1,9 +1,9 @@ = Exchange Pattern -There are two _Message Exchange Patterns_ you can use in +There are two _Message Exchange Patterns_ (MEP) you can use in messaging. -From there xref:components:eips:enterprise-integration-patterns.adoc[Enterprise +From the xref:components:eips:enterprise-integration-patterns.adoc[Enterprise Integration Patterns] they are: * xref:components:eips:event-message.adoc[Event Message] (or one-way) @@ -16,6 +16,30 @@ the Message Exchange indicating if a message exchange is a one way xref:components:eips:event-message.adoc[Event Message] (*InOnly*) or a xref:components:eips:requestReply-eip.adoc[Request Reply] message exchange (*InOut*). +== How Exchange Pattern Works + +The exchange pattern is a contract between the route and the *component endpoint*. +It tells the component whether the caller expects a reply (`InOut`) or not (`InOnly`). + +The exchange pattern does *not* affect how EIPs and processors work within the route. +Processors such as `setBody`, `transform`, `process`, and `bean` always operate on the +current message body regardless of the exchange pattern. +The pattern only matters when the exchange reaches a *producer endpoint* (i.e., a `to` step) +that acts on it. + +Whether a component acts on the exchange pattern depends on the component: + +* *Asynchronous components* such as xref:components::jms-component.adoc[JMS], + xref:components::seda-component.adoc[SEDA], xref:components::kafka-component.adoc[Kafka], + and xref:components::amqp-component.adoc[AMQP] use the pattern to decide between + fire-and-forget (`InOnly`) and request/reply (`InOut`) messaging. + With `InOnly`, the message is dispatched and the route continues immediately without waiting + for a reply. +* *Synchronous components* such as xref:components::direct-component.adoc[Direct] always + process in the same thread and call stack. Setting `InOnly` on a `direct` endpoint + has no practical effect — the caller still waits for the direct route to complete, and any + body changes in the called route are visible to the caller. + For example to override the default pattern on a xref:components::jms-component.adoc[JMS] endpoint you could use the `exchangePattern` parameter in the Endpoint xref:uris.adoc[URI] as shown:
