|
该版本仍在开发中，尚未被视为稳定。对于最新的稳定版本，请使用 Spring Integration 7.0.0！ |
错误处理
正如本手册开头概述所述，像Spring Integration这样面向消息的框架背后的主要动机之一是促进组件间的松耦合。 信息渠道起着重要作用，因为生产者和消费者无需相互了解。 然而，这些优点也有一些缺点。 有些事情在松耦合环境中会变得更复杂，比如错误处理。
在向信道发送消息时，最终处理该消息的组件可能与发送方在同一线程内运行，也可能不是。
如果用简单的默认值直达频道（当<频道>元素<队列>该子元素且无“任务执行者”属性），消息处理发生在发送初始消息的同一线程中。
在这种情况下，如果例外被抛出，可以被发送方接住，或者如果是未接住的，也可能从发送方身边传播运行异常.
这与普通 Java 调用栈中的异常抛出作相同。
运行在调用线程上的消息流可以通过消息网关（参见消息网关）或消息模板（参见消息模板).
无论哪种情况，默认行为都是向调用者抛出任何异常。
关于消息网关，请参见错误处理，了解异常如何抛出以及如何配置网关将错误路由到错误通道。
当使用消息模板或者发送给消息频道例外总是直接抛给呼叫者。
加入异步处理后，情况会变得更复杂。
例如，如果“channel”元素确实提供了“队列”子元素（队列通道在 Java 和注释配置中），处理消息的组件在与发送方不同的线程中运行。
当执行者频道被使用。
发件人可能丢失了消息进入频道，然后转向其他事情。
没有办法例外通过使用标准直接返回给该发送方例外投掷技巧。
相反，处理异步进程的错误需要错误处理机制也是异步的。
Spring Integration 支持通过向消息通道发布错误来处理其组件的错误处理。
具体来说，是例外成为Spring集成的有效载荷错误消息.
那消息然后发送到一个消息通道，该通道的解析方式类似于“replyChannel”的解析。
首先，如果请求消息当时正在处理例外occur 包含一个“errorChannel”头部（头部名称定义于MessageHeaders.ERROR_CHANNEL常数），该错误消息发送到该频道。
否则，错误处理程序会向一个“全局”通道发送，其豆名为errorChannel（这也定义为常数：IntegrationContextUtils.ERROR_CHANNEL_BEAN_NAME).
默认errorChannelBean 由框架内部创建。
不过，如果你想控制设置，可以自己定义。
以下示例展示了如何在XML配置中定义由容量为 的队列支持的错误通道500:
-
Java
-
XML
@Bean
QueueChannel errorChannel() {
return new QueueChannel(500);
}<int:channel id="errorChannel">
<int:queue capacity="500"/>
</int:channel>默认的错误信道是发布订阅频道.
默认情况下，它有日志处理器作为一名拥有错误日志级别和订阅顺序为Ordered.LOWEST_PRECEDENCE - 100.
如果你订阅了额外的消耗端点，可能会触发异常，而且你不想抢占日志记录，确保额外的处理程序有更高的命令。 |
这里最重要的是要明白，基于消息的错误处理仅适用于由 Spring Integration 任务抛出的异常，该任务正在执行于任务执行者.
这不适用于与发送方在同一线程内运行的处理程序抛出的异常（例如，通过直达频道如本节前述所述）。
当调度轮询任务执行中出现异常时，这些异常会被包裹在错误消息实例并发送到“errorChannel”。
这通过消息发布错误处理注入全球任务调度器豆。
建议使用这个消息发布错误处理任何习俗任务调度器如果错误处理仍需使用标准的“errorChannel”集成流程逻辑。
A注册integrationMessagePublishingErrorHandler在这种情况下可以使用豆子。 |
要启用全局错误处理，请在该信道注册一个处理程序。
例如，你可以配置 Spring 集成错误消息异常类型路由器作为订阅于errorChannel.
该路由器随后可以根据例外类型。
从4.3.10版本开始，Spring Integration提供了错误消息发布者以及错误消息策略.
你可以把它当作发布的通用机制错误消息实例。
你可以在任何错误处理场景下呼叫或延长他们。
这ErrorMessageSendingRecoveryer将该类扩展为恢复回调可以与重试一起使用的实现，例如请求处理员再试建议.
这错误消息策略用于构建一个错误消息基于提供的例外和属性访问器上下文。
它可以注射到任何中MessageProducerSupport或MessagingGatewaySupport.
这请求消息存储在ErrorMessageUtils.INPUT_MESSAGE_CONTEXT_KEY在属性访问器上下文。
这错误消息策略可以用那个请求消息作为原始信息的属性错误消息它创造。
这默认错误消息策略正是如此。
从5.2版本开始，所有消息处理异常框架组件抛出的实例，包含一个组件豆子定义资源和源代码用于确定例外中的配置点。
在XML配置的情况下，资源是XML文件路径，源XML标签及其身份证属性。
在 Java 和注释配置中，资源是@Configuration类和源是@Bean方法。
在大多数情况下，目标集成流解决方案基于开箱即用组件及其配置选项。
当异常发生在运行时，栈跟踪中没有涉及任何终端用户代码，因为执行是针对 BEANS，而非其配置。
包含资源和 bean 定义的来源有助于识别可能的配置错误，并提升开发者体验。
从版本 5.4.3 开始，默认错误通道配置为requireSubscribers = true当该频道没有订阅者时（例如应用上下文停止时），不要无声地忽略消息。
在这种情况下，aMessageDispatchingException被抛出，可能使入站通道适配器的客户端回调得以负向确认（或回滚）源系统中的原始消息，以便重新转发或未来考虑。
要恢复之前的行为（忽略未调度的错误消息），可以使用全局集成属性spring.integration.channels.error.requireSubscribers必须设置为false.
参见全局属性和发布订阅频道配置（如果你配置了全局errorChannel手动）以获取更多信息。
另请参见错误处理示例以获取更多信息。