基于Java MDB的ActiveMQ消息长期Pending状态原因排查

核心现象 #

基于Java-MDB搭建的应用以ActiveMQ为消息中间件，部分队列存在少量消息长期处于Pending状态，应用侧未查询到对应消息的消费日志，当前消息确认模式配置为Auto-acknowledge，消费端onMessage逻辑如下：

public void onMessage(Message message) {
    try {
        // Clear all ThreadLocal in SQLQueryHelper.
        SQLQueryHelper.clearCache();
        
        String messageOut = processMessage(message);

        // if there is a reply, send it out
        if (messageOut != null) {
            logger.warn(LoggerKeys.LOG_1_ARGS,
                new String[] {"Reply from MDB not supported. " + messageOut});
        }
    } catch (Throwable e) {
        logger.error(LoggerKeys.LOG_1_ARGS,
            new String[] {"Error encountered: " + e.toString()});
        try {
            //put message on error queue
            handleError(message, e);
        } catch (Throwable e2) {
            //retry to put message on error queue
            handleErrorAndRollBack(message, e2);    
        }
    }
}   

根因定位 #

结合配置和代码逻辑，消息长期卡在Pending状态（已投递未收到ack）且无消费日志，通常由以下几类原因导致：

• 消费线程阻塞，未走到ack触发逻辑
  Auto-acknowledge模式下，MDB容器只会在onMessage方法正常执行返回、且未抛出未捕获异常时才会向Broker回传ack。如果processMessage方法内部出现无限等待、死锁（比如数据库连接池耗尽拿不到连接、下游RPC/HTTP调用无超时配置永久阻塞、分布式锁未释放），消费线程会一直卡在方法内部，既不会执行到后续的日志打印逻辑，也不会返回触发ack，消息会一直被该消费者占用，Broker侧就会显示为Pending状态。
• 僵死消费者持有预取消息，未释放
  ActiveMQ默认存在消息预取机制（Prefetch Policy），消费者连接建立后Broker会提前推送一批消息到消费者本地缓存。如果消费者进程出现假死（TCP连接半开、网络分区但连接未被操作系统回收、进程GC停顿时间过长），Broker会一直认为该消费者存活，预取给它的消息不会重新投递给其他正常消费者，这部分消息在控制台就会显示为长期Pending，正常消费者拿不到消息自然也不会产生消费日志。
• 异常处理逻辑吞掉致命错误，导致ack状态异常
  代码在最外层直接catch了所有Throwable，包含OutOfMemoryError、StackOverflowError这类JVM致命错误。如果执行过程中触发这类错误，JVM可能已经处于资源耗尽状态，catch块内的日志打印、错误队列投递逻辑根本无法执行，方法既无法正常返回触发ack，也不会抛出异常触发容器的消息回收逻辑，最终导致消息一直处于未ack状态。
• 错误分支逻辑未正确触发回滚
  如果handleError、handleErrorAndRollBack方法内部吞掉了异常，没有把消息处理失败的状态传递给MDB容器，容器会误判消息已经处理完成，但实际ack因为逻辑异常没有发送成功，也会导致消息卡在Pending状态。

排查与修复方案 #

• 第一步先定位阻塞点：在出问题的应用节点执行jstack命令导出线程栈，查找ActiveMQ/MDB对应的消费线程，查看线程栈的阻塞位置，确认是否卡在processMessage内部的数据库、下游调用等逻辑，针对性修复阻塞点、给所有远程调用加上合理的超时时间。
• 检查Broker侧的消费者连接：在ActiveMQ控制台查看对应队列的消费者列表，清理长期无数据交互的僵死连接，同时配置连接心跳超时参数wireFormat.maxInactivityDuration=30000，让Broker自动断开30秒无心跳的异常连接，回收预取的消息重新投递。
• 调整异常处理逻辑：onMessage最外层不要捕获Throwable级别异常，仅捕获业务Exception，将JVM致命错误直接抛给容器处理，避免资源耗尽场景下逻辑卡死；同时校验handleErrorAndRollBack的实现，确保异常场景下能正确触发容器的消息回滚，不要吞掉异常。
• 优化预取配置：对于业务处理耗时波动大、容易出现阻塞的队列，适当调小消费者预取值（比如设置为1），避免单消费者异常时占用大量消息无法被其他节点消费。

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