jms - 从 Websphere MQ 读取消息总是破坏性调用

Question

我观察到当从队列中读取消息时(破坏性调用)，如果回滚 TX(MDB 容器管理的 TX)消息被放回队列(原始队列或退出队列，具体取决于倒退计数和阈值设置队列)。假设如果由于 TX 回滚失败而发生某些事情(重复网络问题或某些问题)，则消息将丢失。

这是真的吗？？

谢谢

Answer 1

正如我在对先前问题的评论中指出的那样，简短的回答是“不，如果 COMMIT 失败，WMQ 将不会丢失这些消息”，但让我们更详细地了解一下。

当客户端通过网络连接到 MQ 时，在幕后发生的事情是 MQ 启动一个进程，该进程创建到 MQ 的共享内存连接和到客户端应用程序的套接字连接。保持事务打开的是共享内存进程，在 WMQ 术语中称为“ channel 代理”。

在两种情况下，COMMIT 从应用程序的角度来看似乎已失败。在其中的第一个中，COMMIT 被传送到 channel 代理并执行，但由于网络问题，确认从未返回到应用程序。从 MQ 的角度来看，消息并没有“丢失”，因为应用程序有意提交了 GET 调用。

第二种情况是网络故障发生在COMMIT到达 channel 代理之前。在这种情况下，COMMIT 确实失败了，因为应用程序无法恢复事务所在的连接句柄。当 channel 代理意识到 TCP 连接失败时，它会撤销事务并关闭 channel 。这个过程中的问题是 channel 代理可能需要一段时间才能意识到连接已经中断。事实上，大多数平台上的默认 TCP 超时是两个小时。根据您服务器的 TCP 设置，已处理的 GET 可能会将该消息在同步点下保存最多两个小时，使其看起来已被使用。这是强烈建议使用当前级别的 QMgr 和客户端的原因之一 - 它们较少依赖 TCP，更多地依赖内部 channel 心跳协议(protocol)来检测丢失的连接。

从应用程序的角度来看，这两种情况似乎是相同的 - 应用程序调用 COMMIT 并返回 2009 MQRC_CONNECTION_BROKEN。但在第一种情况下，消息由于 COMMIT 而消失，在第二种情况下，消息可能会再次传递。由于这种歧义，应用必须能够检测并妥善处理欺骗消息。

现在，在宣布这是 MQ 中的一个缺陷之前，让我指出这种结果的模糊性是在通过网络使用消息传递时固有的，而不是 WebSphere MQ 特有的任何东西。事实上，JMS 1.1 specification直接在 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.

因此使用同步点可以消除丢失消息的情况，因为任何 GET 都必须跟在 COMMIT 之后才能从队列中永久删除消息。根据定义，COMMIT 在应用程序看到消息之前无法到达。但是，同步点不能消除重复消息的可能性，因为如果 GET 的 COMMIT 失败，应用程序可能会再次看到该消息。同样，如果 PUT 的 COMMIT 失败，应用程序无法知道 COMMIT 是在到达 channel 代理之前还是之后失败，并且别无选择，只能重新连接并再次 PUT 消息。

如果您确实遇到了“丢失”的消息，则可能是:

1. 放置应用程序在 COMMIT 上失败，但没有放置消息的另一个副本。
2. GET 应用程序在 COMMIT 上失败，消息没有丢失，但实际上在同步点下。在这种情况下，停止任何孤立 channel 以回滚事务。

除了这两种情况，WMQ 不会丢失该持久消息。