我正在处理一个独立的MQ JMS应用程序，我们的应用程序需要“知道”客户端已经消耗了消息生成器放在队列中。因为客户端应用程序不对我们负责。所以我们不能让他们写一些像“msg.acknowledge（）;”的东西。他们身边的事情（msg.acknowledge（）在我的条件下不是正确的方法。）我在stackoverflow中搜索历史答案。找到以下内容与我想要的完全相同：
https://stackoverflow.com/questions/6521117/how-to-guarantee-delivery-of-the-message-in-jms
Do the JMS spec or the various implementations support delivery confirmation of messages?
我的问题是，有没有其他方法可以在MQ API或JMS API中存档它？我只需要在msg产生端进行编码，它可以是队列或主题。
另一个问题是JMS中的确认模式CLIENT_ACKNOWLEDGE，是否产生无关紧要？我一直认为这种模式可以在调用send（）方法时阻塞应用程序，直到客户端使用消息并调用msg.acknowledge（），但似乎不是这样。产品在传递消息后退出应用程序，消息只存储在队列中，直到客户端调用acknowledge（）。那可能让生产者应用程序挂起来等到客户端确认消息吗？
如果我的概念不对，请纠正我，谢谢。
答案 0 :(得分：7)
消息排队的主要目的是解耦生产者和消费者。生产者不需要等待消费者消费消息，它可以继续它的工作。理想情况下，如果生产者需要知道消息是否已经被消费者处理，它应该等待消费者在另一个队列上发送响应消息。
消息确认与生产者无关。消息确认是消息传递提供程序在将消息传递到应用程序后从队列中删除消息的方式。
自动确认JMS提供程序（如MQ JMS）在向应用程序传递消息后告诉消息传递提供程序从队列中删除消息。然后有客户端确认，在收到消息后，应用程序明确告知消息传递提供程序从队列中删除消息。
生产者是否有必要等待消费者接收消息？一种方式，虽然不优雅，但可能是：一旦发送消息，使用已发送消息的消息ID并尝试浏览该消息。如果未找到消息，则可以假设已消耗