ArtemisMQ 2.17地址内存过快占用 队列消息数为0但Broker总消息数激增

异常现象根因 #

• 你使用的ArtemisMQ 2.17版本存在已知的多播（multicast）地址消息缓冲区泄漏缺陷：多播地址下没有匹配的消费者、路由规则临时失效时，消息会被暂存在地址层面的内部缓冲区，既不会计入单队列的消息统计，也不会被自动回收，最终表现为队列显示0但Broker总消息数持续上涨。
• Spring JMS默认的AUTO_ACKNOWLEDGE确认模式在高并发快速拉取场景下，会出现客户端已拉取消息但Broker未收到确认指令就出现会话超时/断开的情况，这部分消息会被标记为在途未确认状态，也不会计入常规队列统计。

未展示在队列中的消息去向 #

• 绝大多数暂存在多播地址的内部消息缓冲区，这部分数据默认不会在./artemis queue stat的队列统计中展示，仅会计入Broker层面的总消息计数。
• 少量为绑定在消费者会话上下文的在途未确认消息，会话未销毁前不会被转移到其他可见队列。

重启后随机出现ExpiryQueue消息的原因 #

Broker重启时会全量扫描所有地址缓冲区、未销毁会话中的残留消息：如果扫描到的残留消息已经超过自身设置的过期时间，就会被自动转移到ExpiryQueue；如果未超过过期时间，会被重新投递到匹配的业务队列，因此该现象是否出现取决于残留消息的过期时间和重启的时间点，属于随机触发。

配置调整方案 #

• 优先将ArtemisMQ升级到2.26及以上正式版本，2.17之后的多个版本已修复多播地址消息泄漏、总计数统计不准的问题，是解决该问题的最优方案。
• 若暂时无法升级，可修改broker.xml进行临时规避：
  • 针对多播地址添加地址配置，强制地址缓冲区残留消息自动过期：

    <address-setting match="你的多播地址前缀#">
      <expiry-delay>300000</expiry-delay> <!-- 5分钟未投递自动过期 -->
      <expiry-address>jms.queue.ExpiryQueue</expiry-address>
    </address-setting>
    

  • 若业务不需要自动创建临时队列，关闭多播地址的自动队列创建开关：<auto-create-queues>false</auto-create-queues>，避免无效临时队列累积消息。
  • 调整Spring JMS消费者的确认模式为CLIENT_ACKNOWLEDGE或开启本地事务，确保只有业务消费成功后才向Broker返回确认指令，减少在途未确认消息的产生。
  • 配置独立的死信地址和死信队列，统一收纳无法投递的消息定期清理，避免占用地址内存。

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