.net IBM MQ客户端在10分钟后断开连接：IBM.XMS.IllegalStateException

我正在使用来自IBM的这个示例。我刚刚复制并粘贴了代码：

我正在连接到MQ服务器版本9.0.0.5 我使用的是控制台应用程序.NETFramework 4.6.1 安装在本地计算机上的MQ客户端是9.1.0.1 我能看到一种非常奇怪的行为。应用程序正常运行，并且能够获取消息。但它会在10分钟后断开。总是10分钟

这是捕获到的错误：

IBM.XMS.IllegalStateException: Failed to get a message from destination MY_QUEUE.
IBM MQ classes for XMS attempted to perform an MQGET; however IBM MQ reported an error.
Use the linked exception to determine the cause of this error.
   at IBM.XMS.Client.Impl.XmsMessageConsumerImpl.ReceiveInboundMessage(Int64 timeout)
   at IBM.XMS.Client.Impl.XmsMessageConsumerImpl.Receive(Int64 millis)
   at Mq_Get_Tests.SimpleConsumer.ReceiveMessages() in C:\Users\osotorrio\Projects\Temporal\Mq_Get_Tests\Mq_Get_Tests\SimpleConsumer.cs:line 137
Linked Exception : CompCode: 2, Reason: 2009*

---

IBM示例是否缺少一些配置设置以允许客户端在10分钟不活动后重新连接？

您描述的症状似乎与APAR匹配

截至2019年8月7日，9.0.0.7和9.1.0.3已发布，可从或下载

要提供一些关于事情应该如何运作的背景信息：

连接到队列管理器的MQ客户端应用程序将协商心跳间隔HBINT，该间隔是以秒为单位的值。协商的HBINT始终是SVRCONN和客户端应用程序之间协商的最高值。 注意：SVRCONN HBINT的默认值为300。 根据HBINT，通过以下两种方式之一计算超时： 如果协商的HBINT小于60，则超时为2x HBINT。接收到的超时为HBINT结束后的HBINT秒 如果协商的HBINT大于或等于60，则超时为HBINT+60。接收超时为HBINT通过后60秒。 如果在HBINT时间段内未收到来自队列管理器的正常通信量，则客户端应向队列管理器发送心跳，队列管理器应作出响应。客户端应等待接收超时时间，以便接收心跳。 队列管理器还可以向客户端发起心跳，但为了防止额外的流量，队列管理器在向客户端发送心跳之前比协商的HBINT多等待5秒钟。 APAR IT26614纠正了以下三个问题：

无论是在非托管模式还是托管模式下，都有记录表明，如果不使用CCDT，HBINT将使用SVRCONN通道的值。实际上，如果不使用CCDT，客户端的HBINT默认为300，因此这是您将看到的最低HBINT

特定于托管.NET，客户端HBINT不能低于SVRCONN HBINT。连接将以2059失败。该问题影响有无CCDT

使用CCDT时，无法将CLNTCONN HBINT设置为小于SVRCONN HBINT的值 如果SVRCONN HBINT设置为301或更高，没有CCDT，您将受到影响 特定于托管.NET，客户端接收超时的计算单位是毫秒，而不是秒。在这种情况下，根据IBM的说法，该缺陷已经存在很长时间了，但直到8.0.0.10和9.0.0.4中引入APAR之后才出现。IBM还确认了GA 9.1.0.0中存在该缺陷。它以前不是问题的原因是托管的.NET从未启动心跳，队列管理器总是在HBINT+5秒时发送心跳，而.NET客户端将响应。一旦纠正了这一点，就会出现接收超时的错误计算

基于托管XMS.NET客户端版本9.1.0.1，我怀疑正在发生这种情况：

无论SVRCONN HBINT设置了什么，HBINT协商到300秒。 托管XMS.NET客户端在300秒未从队列管理器收到任何消息后，将向队列管理器发送心跳。 此时，托管XMS.NET客户端将只等待60毫秒，等待队列管理器的响应。 如果托管XMS.NET客户端在60毫秒内没有收到响应，它将向应用程序返回2009错误。 队列管理器错误日志将显示一个AMQ9209，通过TCP/IP从“dnsname xx.xx.xx.xx”接收数据时出错。 您提到仅在10分600秒时看到这一点，但根据网络的延迟，我在任何300秒的时间间隔内都看到过这一点。如果您连接到同一服务器上或同一本地网段中的队列管理器，则可能永远不会看到此问题。如果您通过高延迟WAN电路连接，则每300秒可能会发生一次。如果通过接近30毫秒的线段连接，您可能会间歇性地看到它

我建议您试用9.0.0.7或9.1.0.3托管XMS.NET客户端，看看它是否能为您解决问题，因为在这些版本中，队列管理器的心跳响应将等待整整60秒

如果要添加重新连接到示例，如果不使用包含APAR IT26614的MQ版本，则会掩盖问题，则可以使用以下设置：

cf.SetIntProperty(XMSC.WMQ_CLIENT_RECONNECT_OPTIONS, XMSC.WMQ_CLIENT_RECONNECT);
cf.SetIntProperty(XMSC.WMQ_CLIENT_RECONNECT_TIMEOUT, XMSC.WMQ_CLIENT_RECONNECT_TIMEOUT_DEFAULT);
//Note that XMSC.WMQ_CLIENT_RECONNECT_TIMEOUT_DEFAULT is 1800

注意：即使您使用带有APAR IT26614的MQ版本，上述操作也是一种良好的做法，因为它会告诉受管的XMS.NET客户端自动尝试重新连接到队列管理器以进行XMSC.WMQ_client_重新连接

---

_如果连接丢失，超时秒数。重新连接不适用于与队列管理器的初始连接，它仅在您连接后才适用。

您在队列管理器错误日志中看到的错误是什么扫描您是否确认在管理模式下调用它？是否提供*系统或*用户作为密钥存储库？@JoshMc密钥存储库的值为*系统。因此，在下面的示例中，属性XMSC_WMQ_CONNECTION_MODE被设置为WMQ_CM_CLIENT=1示例代码捕获消息循环之外的异常。如果要在链接异常为2009时重新连接，则需要捕获循环中的异常，检查它是否为2009-MQRC_CONNECTION_Breaked-然后重新连接。连接可能由于多种原因而中断，并且很可能与网络或防火墙有关。您和MQ队列管理器之间是否存在防火墙？我会问你们网络人防火墙是否正在关闭连接。

cf.SetIntProperty(XMSC.WMQ_CLIENT_RECONNECT_OPTIONS, XMSC.WMQ_CLIENT_RECONNECT);
cf.SetIntProperty(XMSC.WMQ_CLIENT_RECONNECT_TIMEOUT, XMSC.WMQ_CLIENT_RECONNECT_TIMEOUT_DEFAULT);
//Note that XMSC.WMQ_CLIENT_RECONNECT_TIMEOUT_DEFAULT is 1800