+

Search Tips | Advanced Search

Adding a cluster transmit queue to isolate cluster message traffic sent from a gateway queue manager

Modify the configuration of overlapping clusters that use a gateway queue manager. After the modification messages are transferred to an application from the gateway queue manager without using the same transmission queue or channels as other cluster messages. The solution uses an additional cluster transmission queue to separate message traffic to a single queue manager in a cluster.


Before starting

  1. The gateway queue manager must be on Version 7.5, or later.
  2. Construct the overlapping clusters shown in Client-server application deployed to hub and spoke architecture using IBM MQ clusters in Create two-overlapping clusters with a gateway queue manager by following the steps in that task.


About this task

On the gateway queue manager, QM1, add a transmission queue and set its queue attribute CLCHNAME. Set CLCHNAME to the name of the cluster-receiver channel on QM3 ; see Figure 1.

This solution has a number of advantages over the solution described in Adding a remote queue definition to isolate messages sent from a gateway queue manager:

  • It requires fewer additional definitions.
  • It supports workload balancing between multiple copies of the target queue, Q1, on different queue managers in the same cluster, CL2.
  • The gateway queue manager switches automatically to the new configuration when the channel restarts without loosing any messages.
  • The gateway queue manager continues to forward messages in the same order as it received them. It does so, even if the switch takes place with messages for the queue Q1 at QM3 still on SYSTEM.CLUSTER.TRANSMIT.QUEUE.

The configuration to isolate cluster message traffic in Figure 1 does not result in as great an isolation of traffic as the configuration using remote queues in Adding a remote queue definition to isolate messages sent from a gateway queue manager. If the queue manager QM3 in CL2 is hosting a number of different cluster queues and server applications, all those queues share the cluster channel, CL2.QM3, connecting QM1 to QM3. The additional flows are illustrated in Figure 1 by the gray arrow representing potential cluster message traffic from the SYSTEM.CLUSTER.TRANSMIT.QUEUE to the cluster-sender channel CL2.QM3.

The remedy is to restrict the queue manager to hosting one cluster queue in a particular cluster. If the queue manager is already hosting a number of cluster queues, then to meet this restriction, we must either create another queue manager, or create another cluster; see Adding a cluster and a cluster transmit queue to isolate cluster message traffic sent from a gateway queue manager.

Figure 1. Client-server application deployed to hub and spoke architecture using an additional cluster transmission queue.


Procedure

  1. Create an additional cluster transmission queue for the cluster-sender channel CL2.QM3 on the gateway queue manager, QM1. 
     *... on QM1
DEFINE QLOCAL(XMITQ.CL2.QM3) USAGE(XMITQ) CLCHNAME(CL2.QM3)
  2. Switch to using the transmission queue, XMITQ.CL2.QM3.
    1. Stop the cluster-sender channel CL2.QM3. 
      *... On QM1
STOP CHANNEL(CL2.QM3)

      The response is that the command is accepted:


      AMQ8019: Stop IBM MQ channel accepted.
    2. Check that the channel CL2.QM3 is stopped

      If the channel does not stop, we can run the STOP CHANNEL command again with the FORCE option. An example of setting the FORCE option would be if the channel does not stop, and we cannot restart the other queue manager to synchronize the channel. 

      *... On QM1
start

      The response is a summary of the channel status


      AMQ8417: Display Channel Status details.
      CHANNEL(CL2.QM3)             CHLTYPE(CLUSSDR)
      CONNAME(127.0.0.1(1413))     CURRENT
      RQMNAME(QM3)                 STATUS(STOPPED)
      SUBSTATE(MQGET)              XMITQ(SYSTEM.CLUSTER.TRANSMIT.QUEUE)

    3. Start the channel, CL2.QM3. 
      *... On QM1
START CHANNEL(CL2.QM3)

      The response is that the command is accepted:


      AMQ8018: Start IBM MQ channel accepted.
    4. Check the channel started. 
      *... On QM1
DISPLAY CHSTATUS(CL2.QM3)

      The response is a summary of the channel status:


      AMQ8417: Display Channel Status details.
      CHANNEL(CL2.QM3)                   CHLTYPE(CLUSSDR)
      CONNAME(127.0.0.1(1413))           CURRENT
      RQMNAME(QM3)                       STATUS(RUNNING)
      SUBSTATE(MQGET)                    XMITQ(XMITQ.CL2.QM3)

    5. Check the transmission queue was switched.

      Monitor the gateway queue manager error log for the message AMQ7341 The transmission queue for channel CL2.QM3 is XMITQ.CL2.QM3 .


What to do next

Test the separate transmission queue by sending a message from QM2 to Q1 on QM3 using the queue alias definition Q1A

  1. Run the sample program amqsput on QM2 to put a message.
    C:\IBM\MQ>amqsput Q1A QM2
    Sample AMQSPUT0 start
    target queue is Q1A
    Sample request message from QM2 to Q1 using Q1A

    Sample AMQSPUT0 end
  2. Run the sample program amqsget to get the message from Q1 on QM3
    C:\IBM\MQ>amqsget Q1 QM3
    Sample AMQSGET0 start
    message <Sample request message from QM2 to Q1 using Q1A>
    no more messages
    Sample AMQSGET0 end

Parent topic: Create two-overlapping clusters with a gateway queue manager


Related concepts


Related tasks


Related information

Last updated: 2020-10-04