SVRCONN 通道上的 WebSphere MQ DISC 与 KAINT

Question

我们的许多应用程序都存在一个主要问题，即与队列管理器建立不正确的连接（SVRCONN），并且在不需要连接时不发出 MQDISC。这会导致大量空闲的陈旧连接，并阻止应用程序建立新连接，并因 CONNECTION BROKEN (2009) 错误而失败。我们一直在版本 7.0.1.8 上的 Windows MQ 中使用 clientidle 参数限制应用程序连接，但当我们迁移到 Linux 平台中的 MQ v7.5.0.2 时，我们正在决定新版本中可用的最佳选项。v7.5 的 ini 文件中不再有 clientidle，但 SVRCONN 通道中有 DISCINT 和 KAINT。对于我们的应用程序通过 SVRCONN 通道建立连接并保持连接打开而不发出断开连接的场景，我已经了解了两者的优点和缺点。上述哪种渠道属性最适合我们。有什么建议么？其中任何一个优先于另一个吗？

Answer 1

首先，KAINT控制 TCP 功能，而不是 MQ 功能。这意味着要使其生效，Keepalive必须在 TCP 节中启用 TCP 功能qm.ini。这并没有什么问题，但是本机HBINT比DISCINT委托给 TCP 响应更快。这解决了操作系统无法识别套接字的远程伙伴已消失并清理套接字的问题。只要套接字存在并且MQ的通道空闲，MQ就不会注意到。当 TCP 清理套接字时，MQ 的异常回调例程会立即看到它并关闭通道。

在其余两个中，控制 MQ 将终止空闲但活动套接字的DISCINT时间间隔，而控制 MQ 将关闭连接到孤立套接字的 MCA 的时间间隔。理想情况下，您将拥有一个现代 MQ 客户端和服务器，这样您就可以同时使用它们。HBINT

如果您希望通道在生产班次期间保持正常运行，则该DISCINT值应该长于消息之间的最长预期间隔。因此，如果按照设计，通道应至少每 5 分钟有一次消息流量，则DISCINT需要超过 5 分钟才能避免通道重新启动时间。

实际上，它会在通道上传输一条小的心跳消息，但只有在几秒钟后没有收到消息的HBINT情况下才会这样做。HBINTThsi 捕获了套接字已死但 TCP 尚未清理它的情况。 HBINT允许 MQ 在操作系统之前发现并处理它，包括拆除套接字。

一般来说，非常低的值HBINT可能会导致大量不必要的流量。例如，HBINT(5)每五秒间隔发送一次心跳，其中没有其他通道流量通过。有可能，您不需要在套接字丢失后 5 秒内终止孤立通道，因此较大的值可能更有用。也就是说，HBINT(5)在持续消息速率为 1/秒的系统中会导致零额外流量 - 直到应用程序终止，在这种情况下，孤立套接字将很快被终止。

有关更多详细信息，请访问SupportPacs 页面并查找 Morag 的“保持渠道运行”演示文稿。