Home

 

More than one instance of a queue

 

As well as setting up clusters to reduce system administration (as described in Using clusters to ease system administration), we can create clusters in which more than one queue manager hosts an instance of the same queue.

We can organize your cluster such that the queue managers in it are clones of each other, able to run the same applications and have local definitions of the same queues. For example, in a z/OS parallel sysplex the cloned applications might access and update data in a shared DB2 database or a shared Virtual Storage Access Method (VSAM) database. Because we can have several instances of an application each receiving messages and running independently of each other, the workload can be spread between your queue managers.

The advantages of using clusters in this way are:

Any one of the queue managers that hosts an instance of a particular queue can handle messages destined for that queue. This means that applications need not explicitly name the queue manager when sending messages. A workload management algorithm determines which queue manager should handle the message.

Figure 1 shows a cluster in which there is more than one definition for the queue Q3. When an application at QM1 puts a message to Q3, it does not necessarily know which instance of Q3 will process its message.

When an application on QM2 or an application on QM4 puts a message to Q3, the local instance of the queue is used by default, although this depends on how the cluster workload 'use queue' attributes have been set.

If a local queue within the cluster becomes unavailable while a message is in transit, the message is forwarded to another instance of the queue (but only if the queue was opened (MQOPEN) with the BIND_NOT_FIXED open option). If there are no other instances of the queue available, the message is placed on the dead letter queue. If a remote queue or an alias queue within the cluster becomes unavailable while a message is in transit, the message is placed on the dead letter queue.

Figure 1. A cluster with multiple instances of the same queue

If the destination queue manager goes out of service while there is still a message on the transmission queue for it, the system attempts to reroute the message. However, in so doing it does not affect the integrity of the message by running the risk of losing it or by creating a duplicate. If a queue manager fails and leaves a message in doubt, that message is not rerouted.

One factor that can prevent the reallocation of messages by rerouting is whether or not messages have been assigned to a fixed queue manager or channel with BIND_ON_OPEN. In this situation messages are never reallocated to another channel. Another factor to consider is the fact that message reallocation is only driven when a cluster channel is actually failing — the reallocation process is not driven if the channel has already failed.

  1. Before setting up a cluster that has multiple instances of the same queue, ensure that your messages do not have dependencies on each other, for example needing to be processed in a specific sequence or by the same queue manager. See Programming considerations.

  2. Make the definitions for different instances of the same queue identical. Otherwise you will get different results from different MQINQ calls.

Task 3: Adding a new queue manager that hosts a queue shows how to set up a cluster with more than one instance of a queue.

In WebSphere MQ for z/OS, queue managers that are in queue-sharing groups can host cluster queues as shared queues. These cluster queues are therefore available to all other queue managers in the same queue-sharing group. For example, in Figure 1 either or both of the queue managers QM2 and QM4 can be a shared-queue manager. Each has a definition for the queue Q3. If a message is put to the shared queue Q3, on the shared-queue manager QM4, any of the queue managers in the same queue-sharing group can read the message. Because each queue-sharing group can contain up to 32 queue managers, each with access to the same data, this significantly increases the throughput of your messages.

 

Parent topic:

Using clusters for workload management


qc10920_


 

Home