jakarta-ee - 如果客户端崩溃，有人确切知道哪些 JMS 消息将以 CLIENT_ACKNOWLEDGE 模式重新传送吗？

Question

规范说“确认已使用的消息会自动确认已收到其 session 已传送的所有消息”——但我需要知道的是“已传送”的含义。

例如，如果我调用 consumer.receive() 6 次，然后在第 3 条消息上调用 .acknowledge - 是 (a) 仅确认前 3 条消息，还是 (b) 所有 6 条消息？

我真的希望它是选项 a，即在您调用 acknowledge 之后的消息将被重新传送，否则很难看到如果我的接收进程在我有坚持并确认信息的机会。但是规范的措辞并不清楚。我的印象是 JMS 规范的作者考虑了代理故障，但没有花太长时间思考如何防止客户端故障 :o(

谢谢本

Answer 1

根据规范，选项 (b) 是正确的行为。如果您获得选项 (a) 并依赖它，则该应用程序将不可移植。

在下面的解释中，我特指 JMS 规范 2002 年 4 月 12 日的 1.1 版。

当 acknowledge 方法实际上是在 session 级别运行时，它是从消息对象调用的，这引起了一些混淆。因为它是一种消息方法，所以从直觉上来说，可以在消息流中选择一个点来生成确认似乎是正确的。

但真正发生的是消息确认正在插入 session 级别的提交调用。由于 session 一次只能有一个事件事务，因此每个确认不是消息流中的一个点，而是一个时间点。 ack 提交现有的工作单元并开始下一个。在 ack 之前传递的消息必须包含在 ack 提交的工作单元中。

术语“已交付”通常被认为是 API 调用的完成，该调用从队列中删除消息并在程序内存中生成一个填充对象。实际上，当消息从队列中移除时，就认为消息已送达，而不管它是否进入程序。例如，考虑以下事件序列:

1. 该应用请求一条消息。
2. 请求通过 TCP 套接字传递到服务器上的进程，该进程充当应用程序的代理。
3. 代理对队列发出 GET。
4. 消息被锁定在一个工作单元中并传递给代理进程。
5. 代理进程尝试通过 TCP 套接字将消息传递给调用应用程序。如果此时连接被切断，应用程序将永远不会看到该消息，但 JMS 提供者认为它已被传送。当检测到断开的连接时，工作单元将被取消，消息将回滚到队列中并增加重新传送计数。
6. 应用程序收到消息。
7. 应用程序确认消息。
8. 代理进程接收提交调用并执行它。

在 6 和 8 之间有一个窗口，在此期间可以断开 TCP 套接字。在 JMS 提供者端，它无法真正区分这与第 5 步的失败。无论哪种方式，消息都会回滚并稍后重新传送。但是在这种情况下，应用程序将看到该消息两次。该规范在 4.4.13 中预测了这种情况，其中指出:

If a failure occurs between the time a client commits its work on a Session and the commit method returns, the client cannot determine if the transaction was committed or rolled back. The same ambiguity exists when a failure occurs between the non-transactional send of a PERSISTENT message and the return from the sending method.

It is up to a JMS application to deal with this ambiguity. In some cases, this may cause a client to produce functionally duplicate messages.

A message that is redelivered due to session recovery is not considered a duplicate message.

在您“调用 consumer.receive() 6 次，然后在第 3 条消息上调用 .acknowledge”并观察到消息 4 到 6 被重新传送的示例中，可能的解释是 a) 六个消息是并非全部来自同一 session ，或者 b) 行为不符合规范。