我正在处理一个独立的MQ JMS应用程序，我们的应用程序需要"意识到"客户端已经消耗了放入队列的消息生成器。因为客户端应用程序不由我们负责。所以我们不能让他们写一些类似"msg.acknowledge（）"的东西（在我的情况下，msg.ackknowledge（（）不是正确的方法）。我在堆栈中查找历史答案。发现以下是完全相同的我想要的：
https://stackoverflow.com/questions/6521117/how-to-guarantee-delivery-of-the-message-in-jms
JMS规范或各种实现是否支持消息的传递确认？
我的问题是，是否有其他方法可以在MQ API或JMS API中存档？我只需要在消息生成端进行编码，它可以是队列或主题。
另一个问题是，在JMS的确认模式CLIENT_acknowledge中，这会产生无关的结果吗？我一直认为，当调用send（）方法时，这种模式可以阻止应用程序，直到客户端使用消息并调用msg.acknowledge（），但似乎不是这样。product只在消息传递后退出应用程序，消息只存储在队列中，直到客户端调用acknowledge（）。是否可以让生产者应用程序挂在那里，等待客户端确认消息？
如果我的概念不正确，请纠正我，谢谢。
消息排队的主要目的是将生产者和消费者解耦。生产者不需要等待消息被消费者消费，它可以继续它的工作。理想情况下，如果生产者需要知道消息是否已由消费者处理，它应该等待消费者在另一个队列上发送响应消息。
消息确认与生产者无关。消息确认是消费者告诉消息传递提供者在消息传递到应用程序后将消息从队列中移除的方式。
JMS提供程序（如MQ JMS）在将消息传递到应用程序后，会自动确认消息传递提供程序从队列中删除消息。然后是客户端确认，在接收到消息后，应用程序明确地"告诉"消息传递提供程序从队列中删除消息。
生产者必须等待消费者收到消息是有原因的吗？一种方法虽然不优雅，但可以是：一旦发送了消息，就使用发送消息的消息id，并尝试浏览该消息。若并没有找到消息，你们可以假设它已经被消耗了