More than one instance of a queue
Overview
One can create clusters in which more than one queue manager hosts an instance of the same queue.
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. Because you 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:
- Increased availability of your queues and applications
- Faster throughput of messages
- More even distribution of workload in your network
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.
The figure below shows a cluster in which there is more than one definition for the queue Q3. When an application at PARIS puts a message to Q3, it does not necessarily know which instance of Q3 will process its message. (Note, however, that when an application on LONDON or an application on BERLIN puts a message to Q3 the local instance of the queue is used.)
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.
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.
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.
Make the definitions for different instances of the same queue identical. Otherwise you will get different results from different MQINQ calls.
For more information, see: Set up a cluster with more than one instance of a queue.