假设我的配置细节是:
- 1 个将消息发布到 MQ 主题的 PubSub。
- 2 个不同的消费者应用程序。
- 每个消费者 1 个主题订阅。
- 每个订阅 1 个队列。
- 最后每个队列有 1 个回退队列。
谁应该管理回退队列内容并确定应该重新发布哪些内容?
您需要查看的第一件事是:为什么消息首先会在退出队列中结束?
1) 是因为消息格式无效而退出消息的 JMS 客户端吗?
2)消费者应用程序是否由于应用程序错误而回滚消息?
如果问题是上面的#1,您需要查看生产者应用程序并确定消息格式无效的原因。如果是 #2,那么您需要查看您的应用程序逻辑。
最后,您需要有一个应用程序来查看退出队列并采取适当的纠正措施将消息放回订阅队列。
拥有回退队列的应用程序应始终管理回退队列。虽然这在一般情况下是正确的,但在 pub/sub 的情况下尤其如此,因为发布者不可能知道所有订阅者是谁并在整个 MQ 资产中管理他们的回退队列。
反对这一点的一个论点是,特定的应用程序设计确实事先知道消息的接收者。我的回答是,这描述了一个分发列表,而不是专门设计用于将发布者与订阅者分离的发布/订阅。
您描述的实现的替代方法是在所有订阅上使用公共回退队列。您创建一个模型队列,指定预期的公共回退队列,并在主题对象中指定该模型。然后,新订阅会自动将回退消息路由到公共回退队列。然后中央进程或发布者可以管理回退的消息。
请注意,此实现仍然遵循我的建议,即拥有回退队列的应用程序应始终管理回退队列,因为在这种情况下,管理回退消息的应用程序拥有队列。