我们的许多应用程序与队列管理器建立了不正确的连接 (SVRCONN)，并且在不需要连接时没有发出 MQDISC，我们遇到了一个主要问题。这会导致大量空闲陈旧连接并阻止应用程序建立新连接并失败并出现 CONNECTION BROKEN (2009) 错误。我们一直在 Windows MQ 版本 7.0.1.8 中使用 clientidle 参数限制应用程序连接，但是当我们在 Linux 平台上迁移到 MQ v7.5.0.2 时，我们正在决定新版本中可用的最佳选项。我们在 v7.5 的 ini 文件中不再有 clientidle，但在 SVRCONN 频道中有 DISCINT 和 KAINT。对于我们的应用程序通过 SVRCONN 通道建立连接并在不发出断开连接的情况下保持连接打开的场景，我一直在研究两者的优缺点。以上这些渠道属性中的哪一个对我们来说是理想的。有什么建议？这些中的任何一个是否优先于另一个？
【问题讨论】：
标签： ibm-mq channel keep-alive
首先，KAINT 控制 TCP 功能，而不是 MQ 功能。这意味着要使其生效，必须在qm.ini TCP 节中启用 TCP Keepalive 功能。这没有错，但是本机 HBINT 和 DISCINT 比委托给 TCP 响应更快。这解决了操作系统没有识别出套接字的远程伙伴已经消失并清理套接字的问题。只要套接字存在并且 MQ 的通道处于空闲状态，MQ 就不会注意到。当 TCP 清理套接字时，MQ 的异常回调例程会立即看到它并关闭通道。
在其余两个中，DISCINT 控制 MQ 将终止空闲但 活动 套接字的时间间隔，而 HBINT 控制 MQ 将关闭连接到 的 MCA 的时间间隔。 em>孤儿套接字。理想情况下，您将拥有一个现代 MQ 客户端和服务器，因此您可以同时使用这两者。
如果您希望频道在生产班次期间保持正常运行，DISCINT 的值应该比消息之间的最长预期间隔更长。因此，如果按照设计，频道应至少每 5 分钟有一次消息流量，那么将需要超过 5 分钟的DISCINT 以避免频道重启时间。
HBINT 实际上会在通道上传输一个小的心跳消息，但只有在 HBINT 秒后没有消息时才会这样做。 Thsi 捕捉到套接字已死但 TCP 尚未清理它的情况。 HBINT 允许 MQ 在操作系统之前发现并处理它，包括拆除套接字。
一般来说，HBINT 的值非常低会导致大量不必要的流量。例如，HBINT(5) 将每隔五秒发送一次心跳，在此间隔内没有其他通道流量通过。很有可能，您不需要在套接字丢失后 5 秒内终止孤立通道，因此较大的值可能更有用。也就是说，HBINT(5) 将在系统中以 1/秒的持续消息速率导致零额外流量 - 直到应用程序终止，在这种情况下，孤立套接字将很快被终止。
如需了解更多详情，请转至SupportPacs page 并查看 Morag 的“保持频道运行”演示文稿。
【讨论】：