Hi Sean,
as you say, halting the messages at the Gateway or UC QM and deleting them in a cluster is problematic, but perhaps there is an easier way if we restate the requirement.
If instead of saying we need to block the messages, perhaps we can look at it as: we need to prevent the messages from reaching IIB.
Let's assume (or propose if you don't currently have it) that you have a queue alias on each Gateway queue manager that is visible to the QMs in the uniform cluster via the second cluster (The UC/Gateway cluster). This qalias directs messages to the IIB queue managers via a third (IIB/Gateway) cluster.
Instead of trying to block messages from reaching this, or blocking channels so the messages can't reach IIB, why not try:
Create a TOPIC object (DUMMY) on the gateway queue managers.
When you want to ignore incoming messages, alter the queue alias at the Gateway QMs to direct messages to topic DUMMY instead of the normal destination), Since there is no subscription on DUMMY, you don't have to clean up unwanted messages. MQ will just never save them.
If you do sometimes want to review the messages, you can either subscribe and send them to a queue, or just create a local queue and direct the alias to that for the duration of the testing.
When you want messages to be processed by IIB again, just change the alias back.
Regards,
Neil Casey.
------------------------------
Neil Casey
Senior Consultant
Syntegrity Solutions
Melbourne, Victoria
IBM Champion (Cloud) 2019-21
------------------------------
Original Message:
Sent: Fri July 02, 2021 11:06 AM
From: SEAN ADAMS
Subject: Operationally controlling Application data flowing across overlapping clusters.
I have a use case that I'm trying to resolve, so asking for help and guidance of a best approach.<o:p></o:p>
I'm implementing a Uniform Cluster, not only for improved message service availability but to also eliminate an infrastructure single point of failure.<o:p></o:p>
Application data will flow between the UC and an MQ workload balanced Cluster of IIB hosts, via a pair of overlapping Gateway Qmgrs.<o:p></o:p>
<o:p></o:p>
The challenge as I see it is:<o:p></o:p>
To support the daily BAU release testing, the support team require the ability to halt the flow of Application test data / traffic between the source App and target IIB Qmgrs, (whilst still allowing the client application to write messages) also enabling the support teams to clear unwanted test data messages, from the Qmgrs before restarting the flow of "required" test messages again across the clusters.<o:p></o:p>
<o:p></o:p>
Our Current infrastructure uses distributed queuing between the application Qmgr and a single gateway Qmgr (entry into the MQ workload balanced IIB cluster). So the flow of data is easily managed via the sender channels and app message removal from the transmit queues.<o:p></o:p>
<o:p></o:p>
Within the new clustered design, we still need to ability to temporarily halt the traffic flow and delete volume generated test data without the risk of impacting cluster stability by inadvertent removal, of cluster management messages. <o:p></o:p>
<o:p></o:p>
Is there a way to simply, separate app data message traffic, from the inter qmgr cluster maintenance traffic, that would provide the means to control the flow of app messages, which would also give assurances that, that route for cluster transmit only handles application related messages.<o:p></o:p>
<o:p></o:p>
There are options for manually defining cluster XmitQ's with additional cluster channels and to use clustered remotes, but does this negate the workload balanced message routing across the gateway qmgr pair, by effectively defining a more static routing to specific Qmgrs.<o:p></o:p>
<o:p></o:p>
Many Thanks in advance
Sean Adams<o:p></o:p>
------------------------------
SEAN ADAMS
------------------------------