C# 100分钟后发生websphere mq客户端主题静默访问错误

我们正在使用WebSphereMQ中的主题集成通信。 使用MQ的c#库，版本8，dll来自从IBM官方网站下载的mqc8_8.0.0.3_win64.zip。 我们毫无问题地连接到服务器，然后访问指定的主题，将连接设置为持久连接，并提供用户ID。然后，我们进入一个无限循环，每2分钟询问是否有新消息发布在这个主题中。这很有效。如果客户端发布消息，我们就会得到它们。如果我们在不删除订阅的情况下断开连接，我们可以在重新连接并保留消息后恢复订阅。从连接角度看，似乎还可以

问题是，经过一段半中间时间后（只是请求新消息，但每次收到代码2033-没有新消息），有些东西停止工作。但是，没有其他（如网络）错误代码。我们不断地得到代码2033，但我们不能再接收消息，即使它们被放在那里。 如果我们断开连接（完全关闭客户端应用程序）并重新连接，消息就会在那里，并且在另一段时间内可以正常工作

Debuggin通过网络数据包嗅探器发现，在连接和访问主题后大约100分钟后，我们的客户端停止发送“get”消息。但从现在开始，它每5分钟发送一次hearbeat消息——这似乎是客户端（库）的自动功能。 然而，客户端日志显示im实际上仍然发送新消息的请求，每次我都会得到代码2033作为响应，即使消息确实存在。 由于这种每100分钟发生一次的及时方式，我们认为这是某种超时，但我们无法确定什么是超时。 经过一番搜索，我在IBM的文档中找到了以下内容： 关于将断开连接间隔设置为100分钟，但在与另一家公司的MQ服务器管理员联系后，我得到了保证，事实上，他们已将此值设置为0，因此情况不应如此。此外，根据网络嗅探，看起来客户端正在停止Get消息，而不是服务器正在断开我们的连接

还有一个更大的难题。我们尝试了软断开queuemanager的连接，重新连接并重新访问主题，但没有任何帮助，好像即使有queuemanager的新实例，也保留了一些静态字段。我们需要完全关闭客户端程序才能接收消息。一直以来，除了代码2033（没有新消息），我们没有收到任何其他错误消息

现在来看一些代码。 每次连接/重新连接时都会使用此选项：

public void Connect()
{
    MQEnvironment.Hostname = connectionName;//please assume those are correctly filled values
    MQEnvironment.Port = port;
    MQEnvironment.Channel = channelName;
    queueManager = new MQQueueManager(QueueManagerName);
}

接下来我们进入主题

public MQTopic AccessTopic(string topicName)
    {
        MQTopic topic = null;
        topic = queueManager.AccessTopic(topicName, null, MQC.MQSO_CREATE | MQC.MQSO_FAIL_IF_QUIESCING | MQC.MQSO_MANAGED | MQC.MQSO_DURABLE | MQC.MQSO_RESUME, null, "subNameXYZ");
        return topic;
    }

接下来，我们阅读主题。所有函数都使用Try/Catch statemsnts，但为了便于查看，我对它们进行了一些清理。这是一个循环，每2分钟一次

public string ReadTopic(MQTopic topic)
    {
        string strReturn = "";
        if (topic != null)
        {
            try
            {
                queueMessage = new MQMessage();
                queueMessage.Format = MQC.MQFMT_STRING;
                queueGetMessageOptions = new MQGetMessageOptions();
                topic.Get(queueMessage, queueGetMessageOptions);
                strReturn = queueMessage.ReadString(queueMessage.MessageLength);
                queueMessage.ClearMessage();
            }
            catch (MQException exp)
            {
                //checking if code = 2033 "no new message"
            }
        }
        return strReturn;
    }

此外，在访问readtopic之前，每个循环都会检查连接是否正常，如果不正常，则重新连接，如下所示：

public void CheckConnection()
{
    if (!queueManager.IsConnected)
    {
        queueManager.Disconnect();
        queueManager.Close();
        Connect();
    }
}

因此，简而言之：问题是什么会导致我们的连接在每次几乎整整100分钟后停止接收来自主题的消息，即使没有错误消息，并且在这100分钟后会在该主题中发布新消息？

---

附带问题：为什么软重新连接不起作用，为了能够访问消息，我们需要完全关闭程序？

MQ中几乎没有可能导致这种行为的场景。例如，浏览光标可能看不到到达的更新的、优先级更高的消息。不完整的消息组也可以返回2033，尽管队列深度不为零。但是，您的描述不支持将这两种情况作为原因

但是，这一部分似乎表明MQ类中存在缺陷：

Debuggin通过网络数据包嗅探器发现 连接并访问主题100分钟后，我们的客户端停止 发送周期“get”消息。然而，它确实发出了声音 从现在起每5分钟发送一次消息-这似乎是客户端 （图书馆）自动功能。然而，客户端日志显示 事实上，即时通讯仍在发送新消息的请求，而且每次 我一直收到代码2033作为响应，即使消息是 实际上在那里

这些类不能可靠地返回2033，除非它们首先向QMgr请求消息。如果您的数据包捕获完成（即感兴趣的网络流没有穿过未被捕获的线程或套接字），则类报告的行为与实际执行的行为不匹配。如果您能够在跟踪下可靠地复制它，IBM应该能够在PMR中解决它

---

在此之前，您可能会被迫实施一些变通办法，例如定期重新启动应用程序。您还可以尝试创建预定义队列的托管订阅，并将应用程序更改为轮询该队列。如果问题与主题对象隔离，则可以在不干扰该主题的任何其他订阅者的情况下解决问题。

您是否考虑过直接向IBM支持部门提出问题？根据描述，我看不出有任何理由会出现这种情况。谢谢。虽然从技术上讲，我们的问题仍然没有解决，但我接受这一点作为解决方案，因为这可能不是一件容易解决的事情。目前，我们正接近最后期限，并决定使用定期重新启动服务的解决方法，我们将尝试在稍后时间与IBM联系。谢谢，我希望您能够解决这个问题。不过，进行数据包嗅探的要点。很多地方不捕捉这些信息进行调试，但在这种情况下确实很有帮助。