ActiveMQ Classic 5.17.2消费异常：旧消息滞留排查求助

1. ActiveMQ Broker端状态核查 #

• 登录ActiveMQ控制台（默认端口8161）定位目标队列，重点查看滞留旧消息的核心属性：
  • 检查消息是否带有JMSXGroupID属性：若开启了消息分组，崩溃服务器可能持有分组锁，重启DR节点后未重新获取所有权，导致分组内旧消息无法被消费。
  • 查看DeliveryCount值：若投递次数过高，说明消息消费时持续抛出异常但未正确ACK，ActiveMQ将其标记为待重试，但重试策略（如maxDeliveryAttempts）配置不合理导致无法重新投递。
  • 确认死信队列（DLQ）状态：检查滞留消息是否被转移至DLQ，若未转移，核对activemq.xml中的死信策略配置，看是否存在规则未触发的情况（如未设置expireMessagesOnNoConsumer）。
• 检查残留连接：在控制台「Connections」页面，查看是否存在崩溃服务器的未释放连接，这类连接会锁定预取的消息，导致无法被其他消费者获取。

2. WSO2 MI消费端配置验证 #

• 核对消费者ACK模式：若使用客户端ACK模式，崩溃服务器未确认的消息会被ActiveMQ标记为「已投递未确认」，需等待会话超时才会释放；检查axis2.xml或代理服务配置中的ackMode参数，确认是否设置合理的超时时间。
• 检查预取量（prefetchSize）配置：若崩溃服务器的prefetchSize设置过大，会预取一批消息并锁定，需等待ActiveMQ检测到连接失效后才会释放；确认两台MI节点的预取量配置一致，避免单节点占用过多消息。
• 验证DR节点消费者状态：登录MI控制台（默认端口9443），查看DR节点是否成功注册为队列消费者，检查wso2carbon.log是否存在连接ActiveMQ失败、消费者初始化报错等日志。

3. 消息本身有效性测试 #

• 从ActiveMQ控制台将滞留旧消息转发至测试队列，用独立的MI消费者实例测试消费：
  • 若消费失败，说明消息存在格式损坏、序列化错误等问题，导致消费者处理时抛出异常，进而被重复投递或滞留。
  • 若能正常消费，说明问题出在原消费环境的会话锁定或配置冲突上。

4. 性能瓶颈排查 #

• 检查MI节点系统资源：查看正常节点与DR节点的CPU、内存、磁盘IO使用率，若存在资源瓶颈，即使启动DR节点也无法提升消费速度。
• 核查ActiveMQ Broker性能：查看activemq.log中的线程池、存储写入、连接数相关日志，排查是否存在慢查询、磁盘延迟、连接池耗尽等问题，限制消息投递效率。

5. 会话超时配置核查 #

• 检查ActiveMQ的transportConnector配置中的wireFormat.maxInactivityDuration参数：若该值过大，崩溃连接无法被及时检测到，导致锁定的消息长时间无法释放；建议设置合理的超时时间（如30000ms），加速无效连接清理。

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