发送方如何知道消息已被 MQ JMS API 消费？答案

【问题标题】：How can sender know the message already be consumed with MQ JMS API?发送方如何知道消息已被 MQ JMS API 消费？
【发布时间】：2012-02-03 21:45:14
【问题描述】：

我正在处理一个独立的 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 中存档吗？我只需要在味精生产端进行编码，它可以是队列或主题。

另一个问题是JMS中的确认模式CLIENT_ACKNOWLEDGE，是否产生无关紧要？我一直相信这种模式可以在调用 send() 方法时阻塞应用程序，直到客户端消费消息并调用 msg.acknowledge()，但似乎不是这样。产品在消息传递后退出应用程序，消息仅存储在队列中，直到客户端调用确认（）。是否可以让生产者应用挂在那里等到客户端确认消息？

如果我的概念不正确，请纠正我，谢谢。

【问题讨论】：

标签： jms mq

【解决方案1】：

消息队列的主要目的是解耦生产者和消费者。生产者不需要等待消息被消费者消费，它可以继续它的工作。理想情况下，如果生产者需要知道消息是否已被消费者处理，它应该等待消费者在另一个队列上发送响应消息。

消息确认与生产者无关。消息确认是消费者告诉消息传递提供者在消息传递到应用程序后从队列中删除消息的方式。

JMS 提供者（如 MQ JMS）在将消息传递到应用程序后，会自动确认消息提供者从队列中删除消息的位置。然后是客户端确认，在收到消息后，应用程序明确告诉消息传递提供者从队列中删除消息。

生产者必须等待消费者接收消息是否有原因？一种方法虽然不优雅，但可能是：发送消息后，使用已发送消息的消息 ID 并尝试浏览该消息。如果没有找到消息，你可以认为它已经被消费了

【讨论】：

谢谢Shashi，你的回复很有用。我们需要知道消费者从我们这边获取消息并记录时间戳。所以我们需要知道消费者已经收到了消息。使用主题来归档这个怎么样？那有什么不同吗？我知道主题可以同步传递消息。如果我使用持久订阅，是否可以满足我的要求？
顺便说一下，正如你所说，我们可以从队列中检查消息ID，以确定消息是否已经被客户端消费，这就是所谓的JMS浏览吗？我对JMS技术细节不是很熟悉，只是想确定一个方向，然后我可以研究一下。再次感谢。
@Shashi，如果是 MQ(IBM)，客户端是否必须发回已阅读消息的确认？如果不是，那么自动确认何时发送回 q manager ？是在 onMessage 被调用之后吗？
如果使用 AUTO_ACKNOWLEDGE 模式，应用程序不必发送任何确认。它由 JMS 客户端完成。我认为JMS客户端在onMessage方法返回后确认消息。
@Shashi 如果 onMessage 内部出现异常并且线程死亡，那么消息还会在队列中吗？我面临一个类似的问题，其中 onMessage 内部存在异常并且线程由于未处理的异常而死亡。我可以在日志中清楚地看到消息是从队列中读取的，但是如果线程死亡，它不会从队列中删除。你知道这是否是一种预期的行为吗？