MQInput 节点在处理持久和事务性消息的错误时执行以下操作。非事务性消息中的错误将按管理输入节点中的错误中讲述的那样处理。
下表中概述了此操作:
错误事件 | 已连接 failure 终端 | 未连接 failure 终端 | 已连接 catch 终端 | catch 终端未连接 |
---|---|---|---|---|
节点检测到内部错误 | 与 Failure 终端连接的流处理该错误 | 消息放入备用队列;如果失败,节点会重试 | 不适用 | 不适用 |
当节点将消息传播到 out 终端时,out 流中出现异常。 | 不适用 | 不适用 | 与 Catch 终端连接的流处理该错误 | 节点重试 |
当节点将消息传播到 Catch 终端时,与 Catch 终端相连的流中出现异常。 | 已记录下错误,消息被回滚 | 已记录下错误,消息被回滚 | 不适用 | 不适用 |
当节点将消息传播到 Failure 终端时,与 Failure 终端相连的流中出现异常。 | 不适用 | 不适用 | 节点重试 | 节点重试 |
节点会在消息回滚到输入队列时试图重试处理。它将检查消息之前是否已回退;如果已回退,则检查回退计数是否达到(等于)回退阈值。每条消息的回退计数由 WebSphere MQ 保存在 MQMD 中。
创建队列时,指定(或将缺省值设为 0)回退阈值属性 BOTHRESH。如果接受缺省值 0,则节点会将其升为 1。如果检测不到当前值,节点也会将值设为 1。这表示,如果消息之前未回退,则会回退并至少重试一次。
如果在 Failure 终端外发生故障,则会不断重试,直至 MQMD 中的回退计数字段达到为输入队列设置的回退阈值的两倍。达到该限制时,节点会尝试将消息放入另一个队列。
不能废弃消息,因此消息流继续尝试回退消息。它通过将错误写到本地错误日志,记录错误情况。该错误还表明输入队列中消息的 BackoutCount 继续增加。
如果因为两个队列都不存在而发生该情况,可定义上述某个回退队列。如果已清除阻止消息处理的情况,可临时增加 BOTHRESH 属性的值。这样强制正常处理消息。
WebSphere MQ 支持消息组。 您可指定消息属于某个组,然后其处理将通过引用组中的其他消息得以完成(即,落实或回滚所有消息)。当您将分组消息发送到代理时,在当前已配置了消息流且在组消息处理期间无错误发生的情况下,支持该条件。
要配置消息流以便在当前处理分组消息,请按照 MQInput 节点中描述的操作执行。但如果在处理时某条消息时发生错误,则无法保证消息组处理正确。
如果已如所述配置了 MQInput 节点,则在正常情况下,组中所有的消息都在单个工作单元中处理,该工作单元在成功处理组中最后的消息时落实。 然而,如果在处理组中最后的消息前发生错误,则包含接近消息和生成错误消息的工作单元受制于此处文档化的规则所定义的错误处理,这可能导致回退工作单元。
然而,消息流可能成功读取和处理组内剩余的任何消息,并因此在新工作单元中进行处理和落实。当遇到和处理最后的消息时发出落实。因此,如果组内发生错 误,但却不是在首个或最后一个消息上发生,则可能回退组的一部分而落实另一部分。
如果您的消息处理要求需要已特殊方式处理该情况,则您必须提供其他错误处理以处理消息组中的错误。例如,可在数据库中记录消息组的故障,并在检索每条消息时包含有关数据库的检查,如果当前组已遇到错误则强制回滚。这将确保回退整个消息组且不会予以处理,直至所有消息成功完成。