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