Every queue manager in a cluster must refer to one or other of the full repositories to gather information about the cluster and so build up its own partial repository. It is of no particular significance which repository you choose. In this example we choose NEWYORK. Once the new queue manager has joined the cluster it will communicate with both of the repositories.
Every queue manager in a cluster needs to define a cluster-receiver channel on which it can receive message. This is also where we indicate that LOSANGELES can process twice as many messages as NEWYORK. On LOSANGELES define:
DEFINE CHANNEL(TO.LOSANGELES) CHLTYPE(CLUSRCVR) TRPTYPE(TCP) CONNAME(LOSANGELES.CHSTORE.COM) CLUSTER(INVENTORY) DESCR('Cluster-receiver channel for LOSANGELES') CLWLWGHT(2)
Every queue manager in a cluster needs to define one cluster-sender channel on which it can send messages to its first full repository. In this case we have chosen NEWYORK, so LOSANGELES needs the following definition:
DEFINE CHANNEL(TO.NEWYORK) CHLTYPE(CLUSSDR) TRPTYPE(TCP) CONNAME(NEWYORK.CHSTORE.COM) CLUSTER(INVENTORY) DESCR('Cluster-sender channel from LOSANGELES to repository at NEWYORK')
To ensure that the Los Angeles queue manager gets twice as many of the inventory messages as New York, we need to alter the definition of the cluster-receiver channel:
ALTER CHANNEL(TO.NEWYORK) CHLTYPE(CLUSRCVR) CLWLWGHT(1)
Before proceeding, ensure that the inventory application does not have any dependencies on the sequence of processing of messages. See Reviewing applications for message affinities for more information.
See the WebSphere MQ Application Programming Guide for information about how to do this.
The INVENTQ queue, which is already hosted by the NEWYORK queue manager, is also to be hosted by TORONTO. Define it on the TORONTO queue manager as follows:
DEFINE QLOCAL(INVENTQ) CLUSTER(INVENTORY)
Now that you have completed all the definitions, if you have not already done so you should start the channel initiator and, on all platforms, start a listener program on queue manager TORONTO. The listener program listens for incoming network requests and starts the cluster-receiver channel when it is needed. See Establishing communication in a cluster for more information.
The cluster set up by this task looks like this:
The INVENTQ and inventory application are now hosted on two queue managers in the cluster. This increases their availability, speeds up throughput of messages, and allows the workload to be distributed between the two queue managers. Messages put to INVENTQ by either LOSANGELES or NEWYORK are handled by the instance on the local queue manager whenever possible. Messages put by LONDON or PARIS are routed to LOSANGELES or NEWYORK, with twice as many messages being sent to LOSANGELES.
This modification to the cluster was accomplished without you having to make any alterations to the queue managers LONDON and PARIS. The repositories in these queue managers are updated automatically with the information they need to be able to send messages to INVENTQ at LOSANGELES.
Notices |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
csqzah0771 |