Spring/spring-integration
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Gateway Error Channel Doc Polishing

Browse Source 
http://stackoverflow.com/questions/42980410/global-error-channel-not-working/42980900#comment73054207_42980900

Clarify that you need to configure an error channel on the gateway if you don't want
exceptions propagated.
This commit is contained in:
Gary Russell
2017-03-23 12:21:55 -04:00
committed by Artem Bilan
parent df9593a528
commit 515042fa03
2 changed files with 13 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

15
src/reference/asciidoc/configuration.adoc
View File

@@ -147,18 +147,25 @@ Some things become more complicated in a very loosely coupled environment, and o
When sending a Message to a channel, the component that ultimately handles that Message may or may not be operating within the same thread as the sender.
If using a simple default `DirectChannel` (with the `<channel>` element that has no `<queue>` sub-element and no 'task-executor' attribute),
the Message-handling will occur in the same thread as the Message-sending.
the Message-handling will occur in the same thread that sends the initial message.
In that case, if an `Exception` is thrown, it can be caught by the sender (or it may propagate past the sender if it is an uncaught `RuntimeException`).
So far, everything is fine.
This is the same behavior as an Exception-throwing operation in a normal call stack.
However, when adding the asynchronous aspect, things become much more complicated.
A message flow that runs on a caller thread might be invoked via a `Messaging Gateway` (see <<gateway>>) or a `MessagingTemplate` (see <<channel-template>>).
In either case, the default behavior is to throw any exceptions to the caller.
For the `Messaging Gateway`, see <<gateway-error-handling>> for details about how the exception is thrown and how to configure the gateway to route the errors to an error channel instead.
When using a `MessagingTemplate`, or sending to a `MessageChannel` directly, exceptions are always thrown to the caller.
When adding asynchronous processing, things become rather more complicated.
For instance, if the 'channel' element _does_ provide a 'queue' sub-element, then the component that handles the Message _will_ be operating in a different thread than the sender.
The same is true when an `ExecutorChannel` is used.
The sender may have dropped the `Message` into the channel and moved on to other things.
There is no way for the `Exception` to be thrown directly back to that sender using standard `Exception` throwing techniques.
Instead, to handle errors for asynchronous processes requires an asynchronous error-handling mechanism as well.
Instead, handling errors for asynchronous processes requires an asynchronous error-handling mechanism as well.
Spring Integration supports error handling for its components by publishing errors to a Message Channel.
Specifically, the `Exception` will become the payload of a Spring Integration Message.
Specifically, the `Exception` will become the payload of a Spring Integration `ErrorMessage`.
That `Message` will then be sent to a Message Channel that is resolved in a way that is similar to the 'replyChannel' resolution.
First, if the request `Message` being handled at the time the `Exception` occurred contains an 'errorChannel' header (the
header name is defined in the constant: `MessageHeaders.ERROR_CHANNEL`), the `ErrorMessage` will be sent to that channel.

2
src/reference/asciidoc/gateway.adoc
View File

@@ -392,6 +392,8 @@ If you provide a one-way flow, then nothing would be sent back to the caller.
In the case that you want to completely suppress Exceptions, you can provide a reference to the global "nullChannel" (essentially a /dev/null approach).
Finally, as mentioned above, if no "error-channel" is defined at all, then the Exceptions will propagate as usual.
When using the `@MessagingGateway` annotation (see <<messaging-gateway-annotation>>), use the `errroChannel` attribute.
Starting with _version 5.0_, when using a gateway method with a `void` return type (one-way flow), the `error-channel` reference (if provided) is populated in the standard `errorChannel` header of each message sent.
This allows a downstream async flow, based on the standard `ExecutorChannel` configuration (or a `QueueChannel`), to override a default global `errorChannel` exceptions sending behavior.
Previously you had to specify an `errorChannel` header manually via `@GatewayHeader` annotation or `<header>` sub-element.