Mule 4+Anypoint MQ：重投递策略与队列转发次数优先级疑问

环境与配置 #

• 技术栈：Anypoint MQ + Mule Runtime 4.4
• 队列与订阅者配置：
  • 普通队列已绑定死信队列（DLQ），队列端设置：Delivery attempts before reroute = 5
  • Mule订阅者设置：redelivery-policy的maxRedeliveryCount = 2
  • 消息确认模式：自动（Auto）

测试代码 #

<flow name="test-DLQ-flow" >
    <anypoint-mq:subscriber doc:name="Employee Updates Topic Listener" config-ref="Anypoint_MQ_Config" destination="${aemployee-queue}">
        <redelivery-policy maxRedeliveryCount="2" />
        <anypoint-mq:subscriber-type >
            <anypoint-mq:prefetch maxLocalMessages="1" />
        </anypoint-mq:subscriber-type>
    </anypoint-mq:subscriber>

    <set-variable value="#[1/0]" doc:name="Creating an error "  variableName="xyz"/>

    <error-handler >
        <on-error-propagate enableNotifications="true" logException="true" doc:name="On Error Propogate" type="MULE:REDELIVERY_EXHAUSTED">
            <logger level="INFO" doc:name="Logger" />
        </on-error-propagate>
    </error-handler>
</flow>

<anypoint-mq:config name="AP_MQ_Config" doc:name="AP MQ Config"  >
    <anypoint-mq:connection 
        url="some_url" 
        clientId="abcd" 
        clientSecret="xyz" />
</anypoint-mq:config>

测试现象 #

通过1/0主动制造错误后，实际流程如下：

1. 消息首次消费失败，触发2次Mule内部重投递，此时attributes.deliveryCount变为3，抛出MULE:REDELIVERY_EXHAUSTED异常
2. 异常被on-error-propagate捕获记录，但消息未立即进入DLQ
3. 后续又触发2次MULE:REDELIVERY_EXHAUSTED异常，直到attributes.deliveryCount达到队列配置的5次，消息才被移至DLQ

问题 #

1. 是否意味着当同时配置队列端的Delivery attempts before reroute（5次）和订阅者的redelivery-policy.maxRedeliveryCount（2次）时，若使用on-error-propagate重新抛出异常，实际生效的是队列端的配置？
2. 若要让订阅端的maxRedeliveryCount优先生效，是否需要将on-error-propagate改为on-error-continue，同时手动将消息发送到DLQ（因为自动确认模式下不再抛出异常，不会触发队列端的重投递逻辑）？此方案是否正确？

解答 #

问题1答案 #

没错，就是这么回事。当你用on-error-propagate把异常抛回给Anypoint MQ客户端时，MQ会把这条消息标记为未确认状态，进而触发队列端的重投递规则——不管订阅者端设了多少次重投，只要异常传回MQ，就会一直重投到队列配置的5次上限才会进入DLQ。订阅者的maxRedeliveryCount仅控制Mule内部的重投递次数，内部投完抛异常，但只要异常没被吞，MQ那边就会按自己的规则继续处理。

问题2方案确认 #

这个方案是正确的。改成on-error-continue之后，异常不会传回MQ客户端，Mule会自动确认消息（因为用的是自动确认模式），队列端就不会再触发额外重投了，这时候订阅者的maxRedeliveryCount就成了最终的重投上限。但因为自动确认后MQ不会再处理这条消息，你得在on-error-continue里添加手动发送消息到DLQ的逻辑，确保异常消息被正确归档，不会丢失。

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