ActiveMQ Artemis消息无重试入DLQ及监听失效问题求助

一、消息无重试直接进入DLQ（AMQ222149）的原因排查 #

AMQ222149日志表示消息被路由至死信队列，结合你遇到的“消费者从未被调用”及连接警告，重点排查以下方向：

1. 日志详情定位根本原因 #

首先查看AMQ222149日志的完整输出，日志中会明确标注消息进入DLQ的具体原因（如expired、max delivery attempts reached、routing failure等），这是最直接的排查依据。

2. Broker地址规则配置问题 #

检查broker.xml中address-setting的默认配置：

• 若max-delivery-attempts被设置为1，即使消息未被消费，Broker可能误判投递失败直接路由至DLQ（默认值为10）；
• 确认auto-create-queues是否为true，若为false且目标队列未提前创建，消息可能因无法路由进入DLQ；
• 检查dead-letter-address与expiry-address是否配置冲突，若消息过期时间被错误设置，会直接进入过期地址（若未配置则转DLQ）。

3. 客户端连接波动影响 #

AMQ222061（连接失败）、AMQ222107（重连失败）提示网络或Broker连接存在波动：

• 若生产者发送消息后，Broker准备投递时消费者连接断开，且Broker的redelivery-delay或retry-interval配置不合理，可能导致消息被直接标记为死信；
• 检查Broker的acceptor配置中max-connections是否过小，导致并发连接被拒绝，间接引发消息投递异常。

4. 生产者代码的并发问题 #

排查生产者发送消息的逻辑：

• 是否存在线程安全问题，导致偶尔将消息错误发送至DLQ（如队列名称变量被多线程篡改）；
• 检查消息属性是否被错误设置，如_AMQ_EXPIRATION（过期时间）、_AMQ_DLQ（强制路由至DLQ）等。

二、DLQ监听器失效的排查 #

1. 目标队列匹配问题 #

• 登录Artemis控制台确认DLQ的实际名称，确保@JmsListener的destination属性与broker.xml中dead-letter-address的配置完全一致（例如Broker配置dead-letter-address="jms.queue.DLQ"，监听器需写@JmsListener(destination = "jms.queue.DLQ")）；
• 检查DLQ队列是否有消息堆积：若有堆积说明监听器未成功连接；若无堆积则需确认消息是否被其他消费者取走。

2. JMS监听器容器配置问题 #

检查DefaultJmsListenerContainerFactory的配置：

• 确认是否注入了正确的ConnectionFactory，且设置了setPubSubDomain(false)（DLQ为队列，非主题）；
• 检查是否配置了正确的destinationResolver，避免目标地址解析错误。

3. Spring Bean注册与权限问题 #

• 确认@JmsListener所在类是否添加了@Component/@Service注解，且Spring Boot扫描路径包含该类（查看启动日志是否有“Starting JMS listener container for destination 'XXX'”的输出）；
• 检查broker.xml的security-settings，确保当前消费用户拥有DLQ队列的consume权限：

  <security-setting match="DLQ">
    <permission type="consume" roles="your-consumer-role"/>
  </security-setting>
  

三、验证与修复步骤 #

1. 先通过AMQ222149日志详情确定消息进入DLQ的核心原因；
2. 针对连接警告，排查网络稳定性或调整Broker连接数配置；
3. 核对DLQ监听器的目标地址与权限配置，确保监听器正常注册；
4. 若为生产者并发问题，修复线程安全缺陷或消息属性设置逻辑。

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