当 jms 消息的 `jmsdestination` 与 `jmsreplyto` 指向同一队列时，camel 默认可能反复消费自身发出的回复消息，造成死循环；本文提供基于 `jmscorrelationid` 过滤、并发控制与队列清理的三重解决方案。
在使用 Apache Camel 与 ActiveMQ（或其他 JMS 提供商）进行请求-回复（request-reply）集成测试时，若受限于架构无法分离请求与回复队列（即 JMSDestination == JMSReplyTo），极易触发“自循环消费”问题：Camel 在发送回复后，又将该回复作为新入站消息再次拾取、处理，进而无限递归，破坏测试确定性与资源稳定性。
根本原因在于：Camel 的 JmsProducer 在启用 replyToSameDestinationAllowed=true 后，虽允许向原队列发送回复，但默认不区分原始消息与自身生成的回复——两者均被同一消费者监听并处理。
✅ 推荐解决方案：三层防护机制
1. 基于 JMSCorrelationID 的消息过滤（最核心）
Camel 在发送回复时，会自动为无 JMSCorrelationID 的入站消息生成并设置该头（通常基于 JMSMessageID）；若原始消息已携带 JMSCorrelationID，Camel 则直接复用它。因此，原始业务消息通常无此头，而所有由 Camel 发出的回复必含该头。
利用这一行为，在路由入口处添加过滤器，仅处理无 JMSCorrelationID 的消息：
from("activemq:my.queue")
.filter(simple("${header.JMSCorrelationID} == null"))
.to("direct:main") // 主业务逻辑
.end();⚠️ 注意：此方案依赖 Camel 的默认行为（自动填充 JMSCorrelationID）。若客户端代码主动设置了该头，请确保其值具备唯一性和可识别性，并在过滤逻辑中做相应适配（如白名单校验）。
2. 严格限制并发消费者数量
即使加了过滤，多线程竞争仍可能导致“漏判”或状态错乱。需强制单线程串行处理：
ActiveMQComponent component = ActiveMQComponent.activeMQComponent("tcp://localhost:61616");
// 关键：设置 replyTo 相关的并发参数（非通用 consumers）
component.setReplyToConcurrentConsumers(1);
component.setReplyToMaxConcurrentConsumers(1);
context.addComponent("activemq", component);? 提示：concurrentConsumers 对 request-reply 场景无效，必须显式配置 replyToConcurrentConsumers 和 replyToMaxConcurrentConsumers（参见 Camel ActiveMQ 文档）。
3. 确保测试前队列干净
残留消息（如上一测试因异常 rollback 回队列的消息）会干扰当前测试。建议在每个 @Test 方法前执行清理：
@BeforeEach
void cleanQueue() throws Exception {
JmsTemplate template = new JmsTemplate(connectionFactory);
template.setReceiveTimeout(100L);
while (template.receive("my.queue") != null) {
// 持续清空，直到无消息
}
}或更稳妥地使用 Purge 操作（如 ActiveMQ 支持的 queue.browse() + removeMessage()）。
? 补充说明与最佳实践
- 不要依赖 stop() 终止路由：stop() 仅终止当前 Exchange 处理链，不影响消费者持续轮询；它不能解决底层消息循环。
- 避免 rollback() 替代过滤：手动回滚会导致消息重回队列头部，加剧循环风险，且违背幂等设计原则。
- 长期建议仍是物理隔离队列：如答案末尾所述，最终解耦 requestQueue 与 replyQueue 是最健壮、可维护的方案，彻底规避语义混淆。
通过以上三步组合（JMSCorrelationID 过滤 + 单线程消费 + 队列预清理），你可在不修改现有协议的前提下，稳定、可靠地完成集成测试，同时为后续架构演进保留清晰路径。
