Cluster transmission queues and cluster-sender channels
Messages between clustered queue managers are stored on cluster transmission queues and forwarded by cluster-sender channels.
When you display cluster-sender channel you see that it is associated with a transmission queue. At any point in time, a cluster-sender channel is associated with one transmission queue. If you change the configuration of the channel, it might switch to a different transmission queue next time it starts. Run the following MQSC command to display the transmission queues that cluster-sender channels are associated with:
DISPLAY CHSTATUS(*) WHERE(CHLTYPE EQ CLUSSDR)
AMQ8417: Display Channel Status details. CHANNEL(TO.QM2) CHLTYPE(CLUSSDR) CONNAME(126.96.36.199(1416)) CURRENT RQMNAME(QM2) STATUS(STOPPED) SUBSTATE( ) XMITQ(SYSTEM.CLUSTER.TRANSMIT.QUEUE)
The transmission queue shown in the saved channel status of a stopped cluster-sender channel might change when the channel starts again. Selection of default transmission queues by cluster-sender channels describes the process of selecting a default transmission queue; Selection of manually defined transmission queues by cluster-sender channels describes the process of selecting a manually defined transmission queue.
When any cluster-sender channel starts it rechecks its association with transmission queues. If the configuration of transmission queues, or the queue manager defaults, changes, it might reassociate the channel with a different transmission queue. If the channel restarts with a different transmission queue as a result of a configuration change, a process of transferring messages to the newly associated transmission queue takes place. How the process to switch cluster-sender channel to a different transmission queue works describes the process of transferring a cluster-sender channel from one transmission queue to another.
The behavior of cluster-sender channels is different to sender and server channels. They remain associated with the same transmission queue until the channel attribute XMITQ is altered. If you alter the transmission queue attribute on a sender or server channel, and restart it, messages are not transferred from the old transmission queue to the new one.
Another difference between cluster-sender channels, and sender
or server channels, is that multiple cluster-sender channels can open
a cluster transmission queue, but only one sender or server channel
can open a normal transmission queue. Until Version 7.5 cluster connections shared the
single cluster transmission queue,
From Version 7.5 onwards you have the
option of cluster-sender channels not sharing transmission queues.
Exclusivity is not enforced; it is an outcome of the configuration.
You can configure the path a message takes in a cluster so that it
does not share any transmission queues or channels with messages that
flow between other applications. See Clustering: Planning how to configure cluster transmission queues and Adding a cluster and a cluster transmit queue to isolate cluster message traffic sent from a gateway queue manager.
Selection of default transmission queues by cluster-sender channels
A cluster transmission queue is
either a system default queue, with a name that starts with
or a manually defined queue. A cluster-sender channel is associated
with a cluster transmission queue in one of two ways: by the default
cluster transmission queue mechanism, or by manual configuration.
The default cluster transmission queue is set as a queue manager attribute, DEFCLXQ. Its value is either SCTQ or CHANNEL. New and migrated queue managers are set to SCTQ. You can alter the value to CHANNEL.
If SCTQ is
set, the default cluster transmission queue is
Every cluster-sender channel can open this queue. The cluster-sender
channels that do open the queue are the ones that are not associated
with manually defined cluster transmission queues.
If CHANNEL is
set, then the queue manager can create a separate permanent dynamic
transmission queue for every cluster-sender channel. Each queue is
is created from the model queue,
Each cluster-sender channel that is not associated with a manually
defined cluster transmission queue is associated with a permanent-dynamic
cluster transmission queue. The queue is created by the queue manager
when it requires a separate cluster transmission queue for the cluster
destination served by this cluster-sender channel, and no queue exists.
Some cluster destinations can be served by cluster-sender channels associated with manually defined transmission queues, and others by the default queue or queues. In the association of cluster-sender channels with transmission queues, the manually defined transmission queues always take precedence over the default transmission queues.
of cluster transmission queues is illustrated in Figure 1. The only cluster-sender channel not associated
with a manually defined cluster transmission queue is
It is not associated with a manually defined transmission queue, because
none of the channel names in the CLCHNAME attribute
of the transmission queues match
Selection of manually defined transmission queues by cluster-sender channels
A manually defined queue has the transmission queue attribute USAGE attribute set to XMITQ, and the cluster channel name attribute CLCHNAME set to a specific or generic channel name.
If the name in the CLCHNAME queue attribute matches a cluster-sender channel name, the channel is associated with the queue. The name is either an exact match, if the name contains no wildcards, or it the best match, if the name contains wildcards.
- The transmission queue
XMITQ.CL1.QM1has its CLCHNAME attribute set to
CL1.QM1. The definition of the CLCHNAME attribute,
CL1.QM1, has no wildcards, and takes precedence over any other
CLCHNAMEattributes, defined on other transmission queues, that match with wildcards. The queue manager stores any cluster message that is to be transferred by the
CL1.QM1cluster-sender channel on the
XMITQ.CL1.QM1transmission queue. The only exception is if multiple transmission queues have their CLCHNAME attribute set to
CL1.QM1. In that case, the queue manager stores messages for the
CL1.QM1cluster-sender channel on any of those queues. It selects a queue arbitrarily when the channel starts. It might select a different queue when the channel starts again.
- The transmission queue
XMITQ.CL1has its CLCHNAME attribute set to
CL1.*. The definition of the CLCHNAME attribute,
CL1.*, has one trailing wildcard, which matches the name of any cluster-sender channel that starts with
CL1.. The queue manager stores any cluster message that is to be transferred by any cluster-sender channel whose name begins with
CL1.on the transmission queue
XMITQ.CL1, unless there is a transmission queue with a more specific match, such as the queue
XMITQ.CL1.QM1. One trailing wildcard makes the definition less specific than a definition with no wildcards, and more specific than a definition with multiple wildcards, or wildcards that are followed by more trailing characters.
XMITQ.CL.QMis the name of the transmission queue with its CLCHNAME attribute set to
CL*.QM*. The definition of
CL*.QM*has two wildcards, which match the name of any cluster-sender channel that starts with
CL., and either includes or ends with
QM. The match is less specific than a match with one wildcard.
- If no transmission queue has a CLCHNAME attribute
that matches the name of the cluster-sender channel that the queue
manager is to use, then the queue manager uses the default cluster
transmission queue. The default cluster transmission queue is either
the single system cluster transmission queue,
SYSTEM.CLUSTER.TRANSMIT.QUEUE, or a system cluster transmission queue that the queue manager created for a specific cluster-sender channel,
SYSTEM.CLUSTER.TRANSMIT.channelName. Which queue is the default depends on the setting of the queue manager DEFXMITQ attribute.
How the process to switch cluster-sender channel to a different transmission queue works
To change the association of cluster-sender channels with cluster transmission queues, change the CLCHNAME parameter of any transmission queue or the queue manager parameter DEFCLXQ at any time. Nothing happens immediately. Changes occur only when a channel starts. When it starts, it checks whether to continue forwarding messages from the same transmission queue. Three kinds of change alter the association of a cluster-sender channel with a transmission queue.
- Redefining the CLCHNAME parameter of the
transmission queue the cluster-sender channel is currently associated
with to be less specific or blank, or deleting the cluster transmission
queue when the channel is stopped.
- Some other cluster transmission queue might now be a better match for the channel name. Or, if no other transmission queues match the name of the cluster-sender channel, the association must revert to the default transmission queue.
- Redefining the CLCHNAME parameter of any
other cluster transmission queue, or adding a cluster transmission
- The CLCHNAME parameter of another transmission queue might now be a better match for the cluster-sender channel than the transmission queue the cluster-sender channel is currently associated with. If the cluster-sender channel is currently associated with a default cluster transmission queue, it might become associated with a manually defined cluster transmission queue.
- If the cluster-sender channel is currently associated with a default cluster transmission queue, changing the DEFCLXQ queue manager parameter.
If the association of a cluster-sender channel changes, when the channel starts it switches its association to the new transmission queue. During the switch, it ensures that no messages are lost. Messages are transferred to the new transmission queue in the order in which the channel would transfer the messages to the remote queue manager.
The switch process goes through the following transactional steps. If the switch process is interrupted, the current transactional step is resumed when the channel restarts again.
- Step 1 - Process messages from the original transmission queue
- The cluster-sender channel is associated with the new transmission
queue, which it might share with other cluster-sender channels. Messages
for the cluster-sender channel continue to be placed on the original
transmission queue. A transitional switch process transfers messages
from the original transmission queue onto the new transmission queue.
The cluster-sender channel forwards the messages from the new transmission
queue to the cluster-receiver channel. The channel status shows the
cluster-sender channel still associated with the old transmission
- The switch process continues to transfer newly arrived messages as well. This step continues until the number of remaining messages to be forwarded by the switch process reaches zero. When the number of messages reaches zero, the procedure moves onto step 2.
- During step 1, disk activity for the channel increases. Persistent messages are committed off the first transmission queue and onto the second transmission queue. This disk activity is in addition to messages being committed when they are placed on and removed from the transmission queue as part of transferring the messages normally. Ideally, no messages arrive during the switching process, so the transition can take place as quickly as possible. If messages do arrive, they are processed by the switch process.
- Step 2 - Process messages from the new transmission queue
- As soon as no messages remain on the original transmission queue
for the cluster-sender channel, new messages are placed directly on
the new transmission queue. The channel status shows the cluster-sender
channel is associated with the new transmission queue. The following
message is written to the queue manager error log:
AMQ7341 The transmission queue for channel ChannelName is QueueName.
Multiple cluster transmission queues and cluster transmission queue attributes
You have a choice of forwarding cluster
messages to different queue managers storing the messages on a single
cluster transmission queue, or multiple queues. With one queue, you
have one set of cluster transmission queue attributes to set and query,
with multiple queues, you have multiple sets. For some attributes,
having multiple sets is an advantage: for example querying queue depth
tells you how many messages are waiting to be forwarded by one or
a set of channels, rather than by all channels. For other attributes,
having multiple sets is a disadvantage: for example, you probably
do not want to configure the same access permissions for every cluster
transmission queue. For this reason, access permissions are always
checked against the profile for
and not against profiles for a particular cluster transmission queue.
If you want to apply more granular security checks, see Access control and multiple cluster transmission queues.
Multiple cluster-sender channels and multiple transmission queues
A queue manager stores a message on a cluster transmission queue before forwarding it on a cluster-sender channel. It selects a cluster-sender channel that is connected to the destination for the message. It might have a choice of cluster-sender channels that all connect to the same destination. The destination might be the same physical queue, connected by multiple cluster-sender channels to a single queue manager. The destination might also be many physical queues with the same queue name, hosted on different queue managers in the same cluster. Where is a choice of cluster-sender channels connected to a destination, the workload balancing algorithm chooses one. The choice depends on a number of factors; see The cluster workload management algorithm.
In Figure 2,
all channels that might lead to the same destination. For example,
if you define
provide routes to the same destination,
Q1, on two
different queue managers. If the channel
also in CL1, it too is a channel that a message for
take. The cluster membership of
CS.QM1 might be defined
by a cluster namelist, which is why the channel name does not include
a cluster name in its construction. Depending on the workload balancing
parameters, and the sending application, some messages for
be placed on each of the transmission queues,
If you intend to separate message traffic, so that messages for the same destination do not share queues or channels with messages for different destinations, you must consider how to divide traffic onto different cluster-sender channels first, and then how to separate messages for a particular channel onto a different transmission queue. Cluster queues on the same cluster, on the same queue manager, normally share the same cluster channels. Defining multiple cluster transmission queues alone is not sufficient to separate cluster message traffic onto different queues. Unless you separate messages for different destination queues onto different channels, the messages share the same cluster transmission queue.
A straightforward way to separate the channels that messages take, is to create multiple clusters. On any queue manager in each cluster, define only one cluster queue. Then, if you define a different cluster-receiver channel for each cluster/queue manager combination, the messages for each cluster queue do not share a cluster channel with messages for other cluster queues. If you define separate transmission queues for the cluster channels, the sending queue manager stores messages for only one cluster queue on each transmission queue. For example, if you want two cluster queues not to share resources, you can either place them in different clusters on the same queue manager, or on different queue managers in the same cluster.
The choice of cluster transmission queue does not affect the workload balancing algorithm. The workload balancing algorithm chooses which cluster-sender channel to forward a message. It places the message on the transmission queue that is serviced by that channel. If the workload balancing algorithm is called on to choose again, for instance if the channel stops, it might be able to select a different channel to forward the message. If it does choose a different channel, and the new channel forwards messages from a different cluster transmission queue, the workload balancing algorithm transfers the message to the other transmission queue.
In Figure 2,
two cluster-sender channels,
are associated with the default system transmission queue. When the
workload balancing algorithm stores a message on
or any other cluster transmission queue, the name of the cluster-sender
channel that is to forward the message is stored in the correlation
ID of the message. Each channel forwards just those messages that
match the correlation ID with the channel name.
CS.QM1 stops, the
messages on the transmission queue for that cluster-sender channel
are examined. Those messages that can be forwarded by another channel
are reprocessed by the workload balancing algorithm. Their correlation
ID is reset to an alternative cluster-sender channel name. If the
alternative cluster-sender channel is
message remains on
If the alternative channel is
CL1.QM1, the workload
balancing algorithm transfers the message to
When the cluster-sender channel restarts, new messages, and messages
that were not flagged for a different cluster-sender channel, are
transferred by the channel again.
You might change the association
between transmission queues and cluster-sender channels on a running
system. You might change a
CLCHNAME parameter on
a transmission queue, or, change the DEFCLXQ queue
manager parameter. When a channel that is affected by the change restarts,
it starts the transmission queue switching process; see How the process to switch cluster-sender channel to a different transmission queue works.
The simple case is when stopping a cluster-sender channel does not cause the rebalancing process to change the cluster-sender channel that is to forward any messages on the queue. This case is when no other cluster-sender channel can forward the messages to the correct destination. With no alternative cluster-sender channel to forward the messages to their destination, the messages remain flagged for the same cluster-sender channel after the cluster-sender channel stops. When the channel starts, if a switch is pending, the switching processes moves the messages to a different transmission queue where they are processed by the same cluster-sender channel.
The more complex case is where more than one cluster-sender channel can process some messages to the same destination. You stop and restart the cluster-sender channel to trigger the transmission queue switch. In many cases, by the time you restart the channel, the workload balancing algorithm has already moved messages from the original transmission queue to different transmission queues served by different cluster-sender channels. Only those messages that cannot be forwarded by a different cluster-sender channel remain to be transferred to the new transmission queue. In some cases, if the channel is restarted quickly, some messages that could be transferred by the workload balancing algorithm remain. In which case some remaining messages are switched by the workload balancing process, and some by the process of switching the transmission queue.