Before starting to use clusters with multiple definitions of the same queue, examine your applications to see whether there are any that have message affinities, that is, they exchange related messages. With clusters, a message can be routed to any queue manager that hosts a copy of the correct queue, affecting the logic of applications with message affinities.
Suppose for example, you have two applications that rely on a series of messages flowing between them in the form of questions and answers. It might be important that all the questions are sent to the same queue manager and that all the answers are sent back to the other queue manager. In this situation, it is important that the workload management routine does not send the messages to any queue manager that just happens to host a copy of the correct queue.
Similarly, you might have applications that require messages to be processed in sequence, for example a file transfer application or database replication application that sends batches of messages that must be retrieved in sequence.
If you have applications with message affinities, try, to remove the affinities before starting to use clusters.
Removing message affinities improves the availability of applications. If an application that has message affinities sends a batch of messages to a queue manager and the queue manager fails after receiving only part of the batch, the sending queue manager must wait for it to recover before it can send any more messages.
Removing messages affinities also improves the scalability of applications. A batch of messages with affinities can lock resources at the destination queue manager while waiting for subsequent messages. These resources may remain locked for long periods of time, preventing other applications from doing their work.
Furthermore, message affinities prevent the cluster workload management routines from making the best choice of queue manager.
To remove affinities, consider the following possibilities:
If it is not appropriate to modify your applications to remove message affinities, there are a number of other possible solutions to the problem. For example, you can:
The disadvantages to this technique are:
The advantage of this method over the previous one is that some workload balancing is carried out to deliver the first message.
The disadvantage of this method is that the first queue manager must wait for a response to its first message and must be prepared to find and use the ReplyToQMgr information before sending subsequent messages. As with the previous method, if there is more than one route to the queue manager, the sequence of the messages might not be preserved.
By specifying MQOO_BIND_ON_OPEN you force all messages to be routed to the same destination. Therefore applications with message affinities are not disrupted. If the destination is not available, the messages remain on the transmission queue until it becomes available again.
MQOO_BIND_ON_OPEN also applies when the queue manager name is specified in the object descriptor when you open a queue. There might be more than one route to the named queue manager (for example, there might be multiple network paths or another queue manager might have defined an alias). If you specify MQOO_BIND_ON_OPEN, a route is selected when the queue is opened.
An alternative to specifying MQOO_BIND_ON_OPEN on the MQOPEN call, is to modify your queue definitions. On your queue definitions, specify DEFBIND(OPEN), and allow the MQOO_BIND option on the MQOPEN call to default to MQOO_BIND_AS_Q_DEF. See Queue definition commands for more information about using the DEFBIND attribute in queue definitions.
Notices |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
csq68af |