基于Artemis的SpringBoot应用内JMS生产消息无法被MQTT接收器接收

核心机制澄清 #

ActiveMQ Artemis 本身不存在跨协议消息路由的硬性限制，你观察到的“MQTT发消息双端可收、JMS发消息仅JMS端可收”的不对称表现，完全是两类协议默认的地址路由模型差异导致的，不是跨协议互通能力缺失。

不对称现象的底层逻辑 #

• MQTT协议在Artemis 2.17版本的默认实现中，消息投递遵循多播订阅模型：MQTT客户端发送消息后，只要地址匹配，消息会被复制投递到该地址下所有绑定的订阅队列，不管这个队列是JMS消费者创建的、还是MQTT订阅生成的。这也是你测试时MQTT发送的消息能被两类消费者同时接收到的核心原因。
• JMS协议的默认投递行为和目的地语义强绑定：如果你的JMS生产端代码（包括Spring Boot自动装配的模板实现）使用的是点对点队列语义发送消息，消息会走任播路由模型：仅会被投递到该队列直接绑定的消费者，不会泛化分发到同地址下其他类型的订阅（比如MQTT客户端创建的多播订阅队列）。这就直接导致JMS发送的消息根本没有被路由到MQTT消费者对应的队列上。

常见踩坑排查点 #

结合你提到的JMS、MQTT两类Spring Boot集成实现，可优先检查这几个容易出现偏差的配置项：

• 确认JMS生产端的目的地类型：如果代码中调用的是createQueue()创建的发送目的地，天然走点对点路由；如果需要让同地址的MQTT主题订阅能收到消息，需要切换为createTopic()对应的主题语义发送
• 检查Artemis的地址路由配置：ANYCAST类型的地址仅支持点对点投递，MULTICAST类型的地址才会将消息分发给所有绑定的订阅队列，MQTT的默认订阅本身就是走MULTICAST路由的
• 校验两类协议的目标地址是否完全匹配：Artemis 2.17版本默认会为不同协议的目的地自动添加系统前缀（比如JMS队列的jms.queue.前缀、MQTT主题的mqtt.前缀），如果JMS发送的目标地址和MQTT订阅的地址存在前缀、大小写差异，即使名字主体相同，也会因为地址不匹配导致MQTT侧无法收到消息

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