SVRCONN 频道上的 WebSphere MQ DISC 与 KAINT

WebSphere MQ DISC vs KAINT on SVRCONN channels

我们的许多应用程序与队列管理器建立不正确的连接 (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 通道建立连接并在不发出断开连接的情况下保持连接打开的场景,我一直在研究两者的优点和缺点。以上哪些渠道属性最适合我们。有什么建议么?这些中的任何一个都优先于另一个吗?

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

在其余两个中,DISCINT 控制 MQ 将终止空闲但 active 套接字的时间间隔,而 HBINT 控制 MQ 结束后的时间间隔将关闭连接到 orphan 套接字的 MCA。理想情况下,您将拥有现代 MQ 客户端和服务器,以便您可以同时使用这两者。

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

HBINT 实际上会在通道上发送一个小的心跳消息,但只有在 HBINT 秒后没有消息时才会这样做。 Thsi 捕获套接字已死但 TCP 尚未清理它的情况。 HBINT 允许 MQ 在 OS 之前发现并处理它,包括拆除套接字。

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

更多详细信息,请转到 SupportPacs page 并查找 Morag 的 "Keeping Channels Running" 演示文稿。