ibm-mq - SVRCONN channel 上的 WebSphere MQ DISC 与 KAINT

Question

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

Answer 1

首先，KAINT控制 TCP 功能，而不是 MQ 功能。这意味着它生效，TCP Keepalive必须在 qm.ini 中启用该功能TCP 节。这没有错，但是原生 HBINT和 DISCINT比委托(delegate)给 TCP 响应更快。这解决了操作系统没有识别出套接字的远程伙伴已经消失并清理套接字的问题。只要套接字存在并且 MQ 的 channel 处于空闲状态，MQ 就不会注意到。当 TCP 清理套接字时，MQ 的异常回调例程会立即看到它并关闭 channel 。

其余两个中，DISCINT控制 MQ 终止空闲但事件的套接字的时间间隔，而 HBINT控制 MQ 关闭连接到孤立套接字的 MCA 的时间间隔。理想情况下，您将拥有一个现代 MQ 客户端和服务器，因此您可以同时使用这两者。
DISCINT如果您希望 channel 在生产类次期间保持正常运行，则该值应该比消息之间的最长预期间隔长。因此，如果一个 channel 按照设计应该至少每 5 分钟有一次消息流量，那么 DISCINT需要超过 5 分钟才能避免 channel 重新启动时间。
HBINT实际上会在 channel 上传输一个小的心跳消息，但只有在 HBINT 时才会这样做几秒钟过去了，没有消息。 Thsi 捕捉到套接字已死但 TCP 尚未清理它的情况。 HBINT允许 MQ 在操作系统之前发现并处理它，包括拆除套接字。

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

更多详情请访问SupportPacs page并查找 Morag 的“保持 channel 运行”演示文稿。