规范说“确认已消费的消息会自动确认已收到其会话已交付的所有消息”-但我需要知道的是“已交付”的含义。
例如，如果我调用 consumer.receive() 6 次，然后在第三条消息上调用 .acknowledge - 是 (a) 只是前 3 条消息被确认，还是 (b) 全部 6 条？
我真的希望它是选项 a，即在您调用确认之后的消息将被重新传递，否则很难看到在我的接收器进程崩溃的情况下如何防止消息丢失有机会坚持和确认消息。但是该规范的措辞尚不清楚。我的印象是 JMS 规范的作者认为代理失败，但并没有花太长时间思考如何防止客户端失败：o(
谢谢 本
【问题讨论】：
标签： jakarta-ee jms
根据规范，选项 (b) 是正确的行为。如果您获得选项 (a) 并依赖它，则该应用程序将不可移植。
在下面的解释中，我特别指的是 JMS 规范 2002 年 4 月 12 日版本 1.1。
确认方法是从消息对象调用的，而实际上它是在会话级别运行的，这会引起一些混淆。因为它是一种消息方法，所以从直觉上看，可以在消息流中选择一个点来生成确认似乎是正确的。
真正发生的是消息确认正在推动会话级别的提交调用。由于会话一次只能有一个事务处于活动状态，因此每个确认不是在消息流中划定一个点，而是在 时间 中划定一个点。 ack 提交现有的工作单元并开始下一个。在 ack 之前传递的消息必须包含在 ack 提交的工作单元中。
术语“已传递”通常被认为是 API 调用的完成，该调用将消息从队列中移除并导致程序内存中的填充对象。实际上，当消息从队列中移除时，无论它是否进入程序，它都被视为已传递。例如，考虑以下事件序列：
在 6 和 8 之间有一个窗口可以断开 TCP 套接字。在 JMS 提供者方面，它无法真正区分这与第 5 步的失败。无论哪种方式，消息都会回滚并稍后重新传递。但是在这种情况下，应用程序将看到该消息两次。该规范在 4.4.13 中预测了这种情况，其中指出：
如果在客户端提交其对 Session 的工作和 提交方法返回，客户端无法确定事务是否 提交或回滚。发生故障时也存在同样的歧义 在 PERSISTENT 消息的非事务性发送和返回之间 从发送方法。
由 JMS 应用程序来处理这种歧义。在某些情况下，这 可能会导致客户端产生功能上重复的消息。
由于会话恢复而重新传递的消息不被视为 重复消息。
在您的示例中，您“调用 consumer.receive() 6 次，然后在第 3 条消息上调用 .acknowledge”并观察到消息 4 到 6 被重新传递，可能的解释是 a) 这六条消息是并非全部来自同一个会话，或者 b) 行为不符合规范。
【讨论】：