我正在使用 IBM WebSphere MQ 为 Pub/Sub 设置持久订阅。我正在使用他们的 C API。我已设置订阅名称，并且选项中有 MQSO_RESUME。
当我为订阅者设置等待间隔并正确关闭订阅者时，它可以正常工作并重新启动。
但是，如果我强制使订阅者崩溃 (Ctrl-C) 并尝试重新打开它，则会收到 MQSUB 以原因代码 2429 结束，即 MQRC_SUBSCRIPTION_IN_USE。
我在 MQGET 中使用 MQWI_UNLIMITED 作为 WaitInterval 并使用 MQGMO_WAIT | MQGMO_NO_SYNCPOINT | MQGMO_NO_SYNCPOINT | MQGMO_CONVERT 作为我的 MQGET 选项
仅当主题没有该订阅的待处理消息时，才会弹出此错误。如果它有订阅可以恢复的待处理消息，那么它会恢复并忽略该主题中第一条发布的消息
我尝试将心跳间隔更改为 2 秒，但这并没有解决问题。
如何防止这种情况发生？
最佳答案
发生这种情况是因为队列管理器尚未检测到您的应用程序已丢失与队列管理器的连接。您可以通过发出以下 MQSC 命令来查看这一点:-
DISPLAY CONN(*) TYPE(ALL) ALL WHERE(APPLTYPE EQ USER)
您将看到您的应用程序仍列为已连接。一旦队列管理器注意到您的进程已消失，您就可以再次恢复订阅。您没有说明您的连接是本地绑定(bind)连接还是客户端连接，但有一些技巧可以根据连接类型帮助加快连接检测速度。
您说，当您能够恢复时，您没有收到第一条消息，这是因为您正在使用 MQGMO_NO_SYNCPOINT 检索此消息，因此您没有收到该消息已从队列中删除，并且在您强行使其崩溃时正在通过套接字到达客户端应用程序，因此该消息消失了。如果您使用 MQGMO_SYNCPOINT(和 MQCMIT)，您将不会遇到该问题。
您说当队列上仍有消息需要处理时您看不到问题，只有当队列为空时您才会看到问题。我怀疑这里的区别在于，当您强制崩溃时，您的应用程序是否处于 MQGET 等待状态或正在处理消息。显然，当队列中没有消息时，您可以使用 MQWL_UNLIMITED 来保证处于 MQGET 等待状态，但是在处理消息时，您可能会在 MQGET 之外花费的时间比在其中花费的时间更多。
您提到调低心跳间隔，以尝试缩短时间范围，这是一个好主意。你说这没用。请记住，您必须在 channel 的两端进行更改，否则您仍将使用默认的 5 分钟。
关于c - MQSUB 在 pub sub 中结束，原因代码为 2429，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/27788437/