BACKOUT_THRESHOLD设为0时IBM MQ的行为疑问及配置需求

为什么BACKOUT_THRESHOLD=0时两种场景行为不一致？ #

IBM MQ里BACKOUT_THRESHOLD=0的设计逻辑只针对主动回退场景的无限重试，和客户端崩溃/断开的被动场景处理逻辑完全不同：

• 当onMessage抛运行时异常时，客户端会主动给MQ发回退请求，此时因为阈值设为0，MQ直接把消息放回队列头部，触发无限重试——这和你预期的一致。
• 当应用崩溃或停止时，客户端没机会发送确认或回退请求，消息处于“处理中”的in-flight状态。MQ检测到连接断开后，对BACKOUT_THRESHOLD=0的队列会跳过回退计数跟踪和放回操作——因为0值的初衷是“允许无限次主动回退”，不是“处理被动断开的未确认消息”，所以消息不会自动返回输入队列。

怎么配置才能让未确认消息无限返回输入队列，不进退信队列？ #

不能直接靠BACKOUT_THRESHOLD=0实现，得换个配置思路：

• 把BACKOUT_THRESHOLD设成极大值（比如999999），别用0。这样既能实现近似无限次重试，又能让MQ正常跟踪回退计数，客户端崩溃断开时，自动把未确认消息放回队列头部（只要没超过这个极大阈值）。
• 不要配置退信队列（BACKOUT_REQ_Q），留空即可。如果配了退信队列，达到阈值时消息会被转过去；留空的话，即使到了阈值，部分MQ版本会继续重试，不会路由到退信队列。
• 确认队列的DISCONNECT_ACTION是BACKOUT（默认就是这个值），确保客户端断开时，MQ自动回退未确认消息并放回队列。

额外提醒 #

• 别指望BACKOUT_THRESHOLD=0处理被动断开场景，这是MQ的设计限制，0值只作用于主动回退的重试逻辑。
• 用极大阈值模拟无限重试时，要留意监控队列的回退计数，避免因消息本身问题（比如内容错误）导致无限重试浪费系统资源。

内容的提问来源于stack exchange，提问作者Chandula