我们的许多应用程序遇到了一个主要问题，即使用队列管理器进行不正确的连接（SVRCONN），并且在不需要连接时不发出MQDISC。这会导致大量空闲的过时连接，并阻止Application建立新连接，并因CONNECTION BROKEN（2009）错误而失败。我们一直在使用版本7.0.1.8的Windows MQ中的clientidle参数限制应用程序连接，但是当我们迁移到Linux平台中的MQ v7.5.2.2时，我们正在决定新版本中可用的最佳选项。我们在v7.5的ini文件中没有clientidle，但有DISCINT＆amp; SVRCONN频道中的KAINT。我一直在研究应用程序通过SVRCONN通道建立连接的情况以及保持连接打开而不发出断开连接的优点和缺点。以上哪些渠道属性对我们来说是理想的。有什么建议？这些中的任何一个优先于另一个吗？
答案 0 :(得分：4)
首先，KAINT控制TCP功能，而不是MQ功能。这意味着要使其生效，必须在Keepalive TCP节中启用TCP qm.ini功能。这没有错，但是本地HBINT和DISCINT比委派给TCP更具响应性。这解决了操作系统尚未识别出套接字的远程伙伴已经消失并清理套接字的问题。只要套接字存在且MQ的通道空闲，MQ就不会注意到。当TCP清理套接字时，MQ的异常回调例程会立即看到它并关闭该通道。
在剩下的两个中，DISCINT控制MQ将终止空闲但活动套接字的间隔，而HBINT控制MQ关闭MCA之后的间隔附加到孤儿套接字。理想情况下，您将拥有一个现代MQ客户端和服务器，因此您可以使用这两者。
如果您希望频道在制作班次期间保持正常，则DISCINT应该是一个长于消息之间最长预期间隔的值。因此，如果某个频道应按设计每5分钟至少传输一次消息流量，则需要超过5分钟DISCINT以避免频道重启时间。
HBINT实际上会在通道上传输一条小的心跳消息，但只有在HBINT秒没有消息的情况下才会这样做。 Thsi发现套接字已经死了，但TCP还没有清理它。 HBINT允许MQ在操作系统之前发现它并处理它，包括拆除套接字。
通常，HBINT的真正低值会导致大量不必要的流量。例如，HBINT(5)每隔五秒就会发出一次心跳，其中没有其他通道流量通过。可能的情况是，你不需要在丢失套接字后的5秒内终止孤立频道，所以更大的值可能更有用。也就是说，HBINT(5)会在持续消息速率为1 /秒的系统中造成零额外流量 - 直到应用程序死亡，在这种情况下，孤立套接字会很快被杀死。
有关详细信息，请转到SupportPacs page并查找Morag＆＃34;保持频道正常运行＆＃34;介绍