WildFly27 Jakarta10调用acknowledge()后JMS Topic仍重复投递消息至MBean

问题场景与现象 #

• 环境：WildFly 27 standalone-full 实例
• 部署结构：两个独立 EAR 包
  • EAR1：包含有状态本地会话 Bean UserService，当用户未找到时发送 ObjectMessage 至 JMS Topic java:/jms/topic/enterpriseYTopic（Topic 配置在 standalone-full.xml 中，配置代码如下）

    <jms-topic name="topic/enterpriseYTopic" entries="java:/jms/topic/enterpriseYTopic"/>
    

  • EAR2：包含消息驱动 Bean TopicSubscriberSecurityDepartment（继承 MessageHandler），负责接收并处理 Topic 消息，处理完成后调用 message.acknowledge()
• 异常表现：
  • 登录凭证错误触发消息发送时，同一消息被两个线程重复接收，启动 WildFly 时可观察到该 MBean 被初始化两次
  • 将消息类型改为 TextMessage 后，第二条消息出现类型转换异常
  • 若把生产者 UserService 和 MBean 部署在同一 EAR 中，所有异常均消失

核心排查方向 #

1. MBean 重复部署/实例化 #

• 检查 EAR2 的打包结构：确认 ejb-jar.xml 中是否重复定义了 TopicSubscriberSecurityDepartment，或者 EAR 包内是否存在多份相同的 EJB 类文件
• 查看 WildFly 启动日志，搜索 TopicSubscriberSecurityDepartment 相关记录，确认是否有两个不同的部署单元（deployment unit）都初始化了该 MBean
• 检查 standalone-full.xml 的 JMS 配置：确认是否为目标 Topic 创建了重复的持久化订阅，导致同一个 MBean 对应多个订阅者实例

2. 消息确认机制冲突 #

• 核对 MBean 的消息确认模式配置：
  • 如果 MBean 使用 AUTO_ACKNOWLEDGE 模式，手动调用 message.acknowledge() 会导致确认逻辑冲突；若使用 CLIENT_ACKNOWLEDGE，需确保仅在消息处理成功后调用一次，避免重复确认触发重发
  • 检查 @MessageDriven 注解中的 acknowledgeMode 属性，确认配置与手动确认逻辑匹配

3. 跨 EAR 类加载隔离问题 #

• 跨 EAR 部署时，JMS 消息相关类可能存在类加载器隔离问题：
  • ObjectMessage 序列化的对象类会被两个 EAR 的类加载器分别加载，导致反序列化时类实例不兼容；改为 TextMessage 后，若第二条消息是残留的 ObjectMessage（或类加载器导致类型识别错误），就会触发类型转换异常
  • 统一类加载策略：在两个 EAR 中添加 jboss-deployment-structure.xml，强制依赖 WildFly 内置的 javax.jms.api 模块，避免 EAR 自带 JMS 类导致的隔离问题
  • 同 EAR 部署时类加载器一致，因此无类类型不匹配问题，这也印证了类加载隔离是潜在根因

4. JMS 订阅唯一性问题 #

• 检查 MBean 的 @MessageDriven 注解中 activationConfig 配置：确认是否设置了唯一的 clientId 和 subscriptionName，若多个实例共用同一标识，会导致重复订阅，进而重复消费消息

验证步骤 #

1. 先解决 MBean 重复启动问题：清理 EAR2 中的重复配置/类文件，确保部署后仅存在一个 MBean 实例
2. 统一类加载配置：为两个 EAR 添加 jboss-deployment-structure.xml，指定依赖服务器的 JMS 模块
3. 调整消息确认逻辑：根据实际需求选择 AUTO_ACKNOWLEDGE（移除手动确认代码）或 CLIENT_ACKNOWLEDGE（确保仅调用一次确认）
4. 确认订阅唯一性：检查 MBean 的订阅配置，确保每个订阅者的标识唯一

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