WebSphere MQ DISC vs KAINT on SVRCONN channels
We have a big problem with many of our applications that make bad connections (SVRCONN) with the queue manager and do not issue MQDISC when no connection is required. This results in many idle stale connections and prevents applications from making new connections and failing with the CONNECTION BROKEN (2009) error. We limited application connections with the clientidle parameter in our Windows MQ version 7.0.1.8, but when we migrated to MQ v7.5.0.2 on the Linux platform, we decided on the best option available in the new version. We no longer have a clientidle in the ini file for v7.5, but we have DISCINT and KAINT channels in SVRCONN channels. I took advantage of the advantages and disadvantages for both our SVRCONN connection application scenario and for disconnecting connections without causing disconnections.Which of these channel attributes is perfect for us. Any suggestions? Does any of them take precedence over the other?
source to share
First, it KAINT
manages TCP functions, not MQ functions. This means that for it to take effect, the TCP feature Keepalive
must be enabled in the qm.ini
TCP stanza . There is nothing wrong with that, but native HBINT
and DISCINT
more responsive than TCP delegation. This fixes the problem that the OS did not recognize that the remote socket partner went missing and flushed the socket. As long as the socket exists and the MQ channel is inactive, MQ will not notice. When TCP flushes the socket up, the MQ exception callback sees it immediately and closes the channel.
Of the remaining two, DISCINT
controls the interval after which MQ terminates an idle but active socket, while HBINT
controls the interval after which MQ will disconnect the MCA attached to the orphan socket. Ideally, you will have a modern MQ client and server so you can use both of these files.
The value DISCINT
must be greater than the longest expected interval between messages if you want the channel not to move during the production shift. Therefore, if the channel must have message traffic at least once every 5 minutes by design, then it will take DISCINT
more than 5 minutes to prevent the channel from restarting .
HBINT
actually transmits a small message over the pipe, but will only do so if HBINT
seconds have passed without a message. Thsi will catch that the socket is dead, but TCP hasn't cleaned it up yet. HBINT
allows MQ to detect this in front of the OS and take care of it, including ripping off the socket.
In general, really low values for HBINT
can cause a lot of unnecessary traffic. For example, there HBINT(5)
will be a heartbeat every five seconds during which no other channel traffic is being transmitted. most likely you don't need to terminate orphan pipes within 5 seconds of losing a socket, so more important is probably more useful. However, it HBINT(5)
will cause zero additional traffic on the system at a message rate of 1 / second - until the application hides, in which case the orphan socket will be killed pretty quickly.
For more information, go to the SupportPacs page and find Morag's "Keep Channels Running" presentation.
source to share