MQSeries.net :: View topic - Overlapping clusters and cluster channels used

PeterPotkay · Posted: Thu Feb 14, 2008 1:46 pm Post subject:

QM1, QM2, QM3 and QM4 are all in the same 2 overlapping clusters. Lets call them CLUSTER1 and CLUSTER2. Each QM has 2 CLUSRCVR channels, one clustered to each cluster. Same thing with their CLUSSNDRs to the Full Repositories: 2 each and each one is clustered to the specific cluster its for. The Full Repositories use namelists to identify both of these cluster names so the FRs can be FRs for both clusters.

On QM1 and QM2 there is a local clustered q called THIS.QUEUE.1.2. Its clustered to CLUSTER1 only.
On QM3 and QM4 there is a local clustered q called THAT.QUEUE.3.4. Its clustered to CLUSTER1 only.

When an app connected to QM3 or QM4 does a MQPUT to THIS.QUEUE.1.2 there is no problem. Load balancing works. Same thing in reverse. When an app connected to QM1 or QM2 does a MQPUT to THAT.QUEUE.3.4 load balancing works as well. In both cases the apps don't specify a QM name in the MQOPEN or MQPUT1. And I see the channels clustered to CLUSTER1 moving all this traffic.

Here's the problem:
In the above scenario, when the app DOES specify the QM name in the MQOPEN or MQPUT1, the message does make it to the specific instance of the queue, but it looks like some of the messages go over a channel in CLUSTER1, and some messages use the CLUSTER2 channel. That's not good. If the destination q is in CLUSTER1 I need the message to use the CLUSTER1 channels only.

It seems that when a destination QM name is used the cluster workload algorithm on the sending QM sees the destination QM is a member of both clusters and ignores the fact that the destination q is in only one of the clusters, a so produces messages onto the S.C.T.Q. that are eligible for either cluster's channels.

I need the messages from Apps A thru C to go over the channels in CLUSTER1 because those channels have been tuned for lots of very small non persistent messages. Apps D thru F need to have their messages go over the channels in CLUSTER2 because those channels have been tuned for fewer but large and persistent messages.

When round robining is allowed to take place it works as hoped. But when a Reply To Qmgr value is used on the MQOPEN to put a reply back to a particular QM I run into my problem of some little non persistent messages finding themselves in the slow lane and some big messages slowing down my fast lanes (Edith going 45 in the left hand lane with the blinker on for the last 5 miles).

Any ideas how to get around this? I came up with a real convoluted way that might work using QM Aliases and ReplyTo Aliases but hope to avoid that. But it presumes the requesting app has to now set a specific value for the Reply To Queue Manager, instead of leaving it blank and letting the QM automagically fill it in. I depend on that behavior because the app (Websphere Message Flows in this case) can run on multiple QMs. I will have to either make the flows add code that query what QM they are connected to (I assume that's possible), and then append the proper suffix depending on which QM in which environment they are in (big CASE statement). Or use Reply To Aliases in conjunction with the QM Aliases.
That's why I said convoluted. Its tuff enough explaining the routing in overlapping clusters to customers. Adding ReplyTo Aliases and QM Aliases on top of that, oh boy. I was hoping for another way.

While I agree its working as designed when it comes to routing when a QM name is present, do you think that's the way it *should* be? Would it be bad for a QM that was routing messages in overlapping clusters to check the q name as well as the QM name if it checks the q name anyway when only the q name is provided? If everyone says it's a bogus idea I'll make due with Aliases. But if you all think it makes sense I'll open an enhancement request. Is it a "bug", or at least a deficiency that both clusters' channels are being used in this scenario?
_________________
Peter Potkay
Keep Calm and MQ On