Checking that the other end of the channel is still available
Heartbeats
You can use the heartbeat-interval channel attribute to specify that flows
are to be passed from the sending MCA when there are no messages on the transmission
queue. This is described in Heartbeat interval (HBINT).
Keep Alive
In WebSphere MQ for z/OS, if you are using TCP/IP as the transport protocol, you can
also specify a value for the KeepAlive Interval channel attribute (KAINT).
You are recommended to give the KeepAliveInterval a higher value than the
heartbeat interval, and a smaller value than the disconnect value. You can
use this attribute to specify a time-out value for each channel. This is described
in KeepAlive Interval (KAINT).
In WebSphere MQ for iSeries, UNIX(R) systems, and Windows systems, if you are using TCP as
your transport protocol, you can set keepalive=yes. If you specify
this option, TCP periodically checks that the other end of the connection
is still available, and if it is not, the channel is terminated. This is described
in KeepAlive Interval (KAINT).
If you have unreliable channels that are suffering
from TCP errors, use of KEEPALIVE will mean that your channels are more likely
to recover
You can specify time intervals to control the behavior of the KEEPALIVE
option. When you change the time interval, only TCP/IP channels started after
the change are affected. The value that you choose for the time interval should
be less than the value of the disconnect
interval for the channel.
For more information about using the KEEPALIVE option on z/OS, see WebSphere MQ for z/OS Concepts and Planning Guide . For other platforms, see the chapter about setting up communications
for your platform in this manual.
Receive Time Out
If you are using TCP as your transport protocol, the receiving
end of an idle non-MQI channel connection is also closed if no data is received
for a period of time. This period of time is determined according to the HBINT
(heartbeat interval) value.
In WebSphere MQ for iSeries, UNIX systems, and Windows systems, the time-out value is set
as follows:
- For an initial number of flows, before any negotiation has taken place,
the timeout is twice the HBINT value from the channel definition.
-
When the channels have negotiated a HBINT value, if HBINT
is set to less than 60 seconds, the timeout is set to twice this value. If
HBINT is set to 60 seconds or more, the timeout value is set to 60 seconds
greater than the value of HBINT.
In WebSphere MQ for z/OS, the time-out value is set as follows:
- For an initial number of flows, before any negotiation has taken place,
the timeout is twice the HBINT value from the channel definition.
- If RCVTIME is set, the timeout is set to one of
- the negotiated HBINT multiplied by a constant
- the negotiated HBINT plus a constant number of seconds
- a constant number of seconds
depending on the RCVTTYPE parameter, and subject to
any limit imposed by RCVTMIN. If you use a constant value of RCVTIME and you
use a heartbeat interval, do not specify an RCVTIME less than the heartbeat
interval. For details of the RCVTIME, RCVTMIN and RCVTTYPE attributes, see
ALTER QMGR in WebSphere MQ Script (MQSC) Command Reference.
Notes:
- If either of the above values is zero, there is no timeout.
- For connections that do not support heartbeats, the HBINT value is negotiated
to zero in step 2 and hence there is no timeout, so you must use TCP/IP KEEPALIVE.
- For client connections, heartbeats are only flowed from the server when
the client issues an MQGET call with wait; none are flowed during other MQI
calls. Therefore, you are not recommended to set the heartbeat interval too
small for client channels. For example, if the heartbeat is set to ten seconds,
an MQCMIT call will fail (with MQRC_CONNECTION_BROKEN) if it takes longer
than twenty seconds to commit because no data will have been flowed during
this time. This can happen with large units of work. However, it should not
happen if appropriate values are chosen for the heartbeat interval because
only MQGET with wait should take significant periods of time.
- Aborting the connection after twice the heartbeat interval is valid because
a data or hearbeat flow is expected at least every heartbeat interval. Setting
the heartbeat interval too small, however, can cause problems, especially
if you are using channel exits. For example, if the HBINT value is one second,
and a send or receive exit is used, the receiving end will only wait for two
seconds before aborting the channel. If the MCA is performing a task such
as encrypting the message, this value might be too short.