ActiveMQ 出队消息的重新传递答案

【问题标题】：Rederlivery of ActiveMQ dequeued messageActiveMQ 出队消息的重新传递
【发布时间】：2022-02-14 23:48:52
【问题描述】：

我有一个 Spring Boot 应用程序，它将 JSON 消息推送到一个队列，而在另一个地方，它使用 @JmsListener 使用这些 JSON 消息。然后通过 HTTP Post 请求发送这些消息。响应代码可能是 200，这没关系，但我想处理客户端关闭或只是响应代码与 200 不同的情况。

有什么机制可以用来重试消息吗？也许我可以在队列末尾推回消息并重试它们，让我们说 3 次？在消息实际出队后，是否有任何内部 ActiveMQ 机制可以做到这一点？

【问题讨论】：

看看ActiveMQ的redelivery policy。
您好，感谢您的链接。我研究了它，但不知道如何在我的场景中实现它：Spring Boot 应用程序 + 嵌入式 ActiveMQ 和 @JmsListener。
您并未真正提供有关如何配置应用程序的任何详细信息，因此无法就如何应用重新交付政策提供可靠的建议。
你有没有把这个排序？

标签： java spring-boot activemq spring-jms

【解决方案1】：

听起来您正在寻找消费者和 HTTP Post 之间的事务。在您的代码调用 session.commit() 之前，JMS 不会确认队列中的消息。然后，您最多可以调用一个 HTTP 端点并保持合理的事务和单一消息传递服务质量。

实现这种自我修复的关键是检测无效的消息负载（即错误的 JSON 格式或错误的数据）并将这些消息移动到 DLQ 中。

考虑添加 JMS 本地事务支持而不是使用 AUTO_ACKNOWLEDGE

connection.createSession(true, Session.SESSION_TRANSACTED);

然后在你的伪代码中：

  Message message = session.receive ..
  .. do valid message checks
  .. call HTTP endpoint..

  // now take action based on HTTP return code
  switch(httpReturnCode)
  case 200:
    session.commit();
  case .. invalid message returned from HTTP:
    .. produce message to DLQ for inspection
    session.commit();
  case .. http not available..:
    .. do some time delay, retry to http endpoint

【讨论】：

在“从 HTTP 返回无效消息”的情况下，您似乎想要调用 session.rollback() 而不是 session.commit() 并让可配置的 redelivery policy 负责重新传递消息或将其发送到 DLQ。如果rollback 不可行，那么使用事务就没有多大价值。