Stopping and quiescing channels
Message channels are designed to be long-running connections between queue
managers with orderly termination controlled only by the disconnect interval
channel attribute. This mechanism works well unless the operator needs to
terminate the channel before the disconnect time interval expires. This can
occur in the following situations:
- System quiesce
- Resource conservation
- Unilateral action at one end of a channel
In this case, you can stop the channel. You can do this using:
- the STOP CHANNEL MQSC command
- the Stop Channel PCF command
- the WebSphere MQ Explorer
- other platform-specific mechanisms, as follows:
- For z/OS:
- The Stop a channel panel
- For i5/OS:
- The ENDMQMCHL CL command or the END option on the WRKMQMCHL panel
There are three options for stopping channels using these commands:
- QUIESCE
- The QUIESCE option attempts to end the current batch of messages before
stopping the channel.
- FORCE
- The FORCE option attempts to stop the channel immediately and may require
the channel to resynchronize when it restarts because the channel may be left
in doubt.
- TERMINATE
- The TERMINATE option attempts to stop the channel immediately, and terminates
the channel's thread or process.
Note that all of these options leave the channel in a STOPPED state, requiring
operator intervention to restart it.
Stopping the channel at the sending end is quite effective but does require
operator intervention to restart. At the receiving end of the channel, things
are much more difficult because the MCA is waiting for data from the sending
side, and there is no way to initiate an orderly termination
of the channel from the receiving side; the stop command is pending until
the MCA returns from its wait for data.
Consequently there are three recommended ways of using channels, depending
upon the operational characteristics required:
- If you want your channels to be long running, you should note that there
can be orderly termination only from the sending end. When channels are interrupted,
that is, stopped, operator intervention (a START CHANNEL command) is required
in order to restart them.
- If you want your channels to be active only when there are messages for
them to transmit, you should set the disconnect interval to a fairly low value.
Note that the default setting is quite high and so is not recommended for
channels where this level of control is required. Because it is difficult
to interrupt the receiving channel, the most economical option is to have
the channel automatically disconnect and reconnect as the workload demands.
For most channels, the appropriate setting of the disconnect interval can
be established heuristically.
- You can use the heartbeat-interval attribute to cause the sending MCA
to send a heartbeat flow to the receiving MCA during periods in which it has
no messages to send. This releases the receiving MCA from its wait state and
gives it an opportunity to quiesce the channel without waiting for the disconnect
interval to expire. Give the heartbeat interval a lower value than the value
of the disconnect interval.
Notes:
- You are advised to set the disconnect interval to a low value, or to use
heartbeats, for server channels. This is to allow for the case where the requester
channel ends abnormally (for example, because the channel was canceled) when
there are no messages for the server channel to send. If the
disconnect interval is set high and heartbeats are not in use, the server
does not detect that the requester has ended (it will only do this the next
time it tries to send a message to the requester). While the server is still
running, it holds the transmission queue open for exclusive input in order
to get any more messages that arrive on the queue. If an attempt is made to
restart the channel from the requester, the start request receives an error
because the server still has the transmission queue open for exclusive input.
It is necessary to stop the server channel, and then restart the channel from
the requester again.