我正在使用IBM WebSphere MQ为Pub / Sub设置持久订阅。我正在使用他们的C API。我已经设置了订阅名称，并且在我的选项中有MQSO_RESUME。
当我为我的订户设置等待间隔并且我正确关闭我的订户时，它工作正常并重新启动正常。
但如果我强行让我的订阅者崩溃（Ctrl-C）并尝试重新打开它，我会得到MQSUB ended with reason code 2429 MQRC_SUBSCRIPTION_IN_USE.
我在MQWI_UNLIMITED中使用WaitInterval作为我的MQGET，并使用MQGMO_WAIT | MQGMO_NO_SYNCPOINT | MQGMO_CONVERT作为我的MQGET选项
仅当主题没有该订阅的待处理消息时，才会弹出此错误。如果它具有可以恢复订阅的待处理消息，则它将恢复并忽略该主题中的第一个已发布消息
我尝试将心跳间隔更改为2秒并且没有修复它。
如何防止这种情况？
答案 0 :(得分：0)
这是因为队列管理器尚未检测到您的应用程序已丢失与队列管理器的连接。您可以通过发出以下MQSC命令来查看： -
DISPLAY CONN(*) TYPE(ALL) ALL WHERE(APPLTYPE EQ USER)
您将看到您的应用程序仍然列为已连接。一旦队列管理器注意到您的进程已经消失，您将能够再次恢复订阅。您没有说您的连接是本地绑定连接还是客户端连接，但有一些技巧可以帮助加快连接检测速度，具体取决于连接类型。
您说在您能够恢复的时候没有收到第一条消息，这是因为您正在使用MQGMO_NO_SYNCPOINT检索此消息，因此您未收到的消息已从在你强行崩溃它的时候，队列正在从套接字到客户端应用程序的路上，所以消息就消失了。如果您使用MQGMO_SYNCPOINT，（和MQCMIT），则不会出现此问题。
您说当队列中仍有待处理的消息时您没有看到问题，您只在队列为空时才看到它。我怀疑这里的不同之处在于您的应用程序是否在MQGET - 等待或在您强行崩溃时处理消息。显然，当队列中没有留言时，您需要使用MQWL_UNLIMITED来保持MQGET - 等待，但在处理消息时，您可能会花更多时间在MQGET而不是它。
你提到调整心跳间隔，试图缩短时间范围，这是一个好主意。你说它没用。请记住，您必须在频道的两个端更改它，否则您仍将使用默认的5分钟。