| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Can Remote Queue pointing to Alias Q |
« View previous topic :: View next topic » |
| Author |
Message
|
| dextermbmq |
 Posted: Sat Jul 04, 2020 5:55 am Post subject: Can Remote Queue pointing to Alias Q |
 |
|
Voyager
Joined: 26 Jul 2014
Posts: 77
|
Hi All,
I am working on below scenario
3-rd Party IBM MQ connecting to my org's Queue Manager [let's call it GatewayQM] over distributed setup (SDR/RCVR channel). I want to load balance the incoming load from the 3-rd Party on 2 underlying Queue Managers[Lets call them APPQM1 and APPQM2].GatewayQM,APPQM1 and APPQM2 are all in one cluster.
We do not want to include a 3-rd Party Queue Manager in our MQ Cluster hence the 3-rd Party Queue Manager is connecting via Distributed Setup to GatewayQM.
I created a ALIAS Queue on GatewayQM and the target queues are clustered on Queue Managers APPQM1 and APPQM2. The Alias Queue is shared with the 3-rd Party Queue manager to add it as RNAME on the remote queue they have created at their end.
However , all the messages are being routed to DEAD LETTER QUEUE on the GatewayQM when the load is pushed on the Remote Queue on 3-rd Party Queue manager. When I checked the reason from DLQ I found the reason as MQRC 2082
00000000: 444C 4820 0100 0000 2208 0000 494D 4941 'DLH ...."...XXX'
----------------------------
mqrc 0x00000822
2082 0x00000822 MQRC_UNKNOWN_ALIAS_BASE_Q
---------------------------
The target queues are correctly added to cluster, if I directly post the messages to aliasq, they are correctly being routed to target queues on APPQM1 and APPQM2.
Is there any constraint that Remote Queue can't have Alias Queue as RNAME ??
3-rd Party------------[SDR/RCVR CHANNEL]----------->GatewayQM
Remote queue on 3-rd Party Queue Manager has "ALIAS QUEUE" as RNAME. The ALIAS Queue is created on GatewayQM
Alias Queue on GatewayQM------------>Target Queues clustered on APPQM1 and APPQM2
QUEUE MANAGER LOGS
========================
AMQ9544W: Messages not put to destination queue.
EXPLANATION:
During the processing of channel '<xxx>' one or more messages could not be
put to the destination queue and attempts were made to put them to a
dead-letter queue. The location of the queue is 1, where 1 is the local
dead-letter queue and 2 is the remote dead-letter queue.
ACTION:
Regards |
|
| Back to top |
|
 |
| exerk |
| Posted: Sat Jul 04, 2020 12:22 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Personally I would do it differently:
1. The third-party would have a QR of QREMOTE(<their symbolic name>) RNAME(<your symbolic name>) RQMNAME(<a cluster queue manager alias>) XMITQ(<your gateway queue manager name>), for example
QREMOTE('DEXTERMBMQ.APPLICATION') RNAME('DXMBMQAPP') RQMNAME('DXCL01') XMITQ('DEXGW')
2. Your gateway queue manager would have a QR matching the RQMNAME you gave the third-party, for example
QREMOTE('DXCL01') RNAME(' ') RQMNAME(' ')
3. Your application queue managers would each have a QALIAS named DXMBMQAPP, with a target of the application queue you want it to go to. Share that QALIAS in the cluster, for example
QALIAS('DXMBMQAPP') TARGTYPE(QUEUE) TARGET(<your actual queue name>) CLUSTER(<your cluster name>)
This gives you flexibility and load-balancing across the cluster, and I'm sure someone will be along soon to provide a more elegant solution.
NB: Don't forget cluster security aspects - you do NOT want a third-party to have the ability to enumerate resources and spray messages across your cluster!
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| dextermbmq |
| Posted: Sun Jul 05, 2020 4:43 am Post subject: |
|
|
Voyager
Joined: 26 Jul 2014
Posts: 77
|
Thanks exerk for the detailed approach. Some more reading fetched me a good read link which shows similar setup
https://www.ibm.com/developerworks/websphere/library/techarticles/1212_bhat/1212_bhat.html?ca=drs-
But I am still unable to figure out on why having an Alias queue on Gateway Queue manager (and putting alias queue in the RNAME of Queue Remote) would not work.
Another doubt (may be a silly one), I was of the view that the messages when sit on the transmission queue have a transmission header that carries the details of Remote Queue Manager and Remote Queue. The transmission header is validated by the Remote/Receiver Queue Manager MCA. If the details of RNAME and RQMNAME is not correct receiver MCA either places the message on DEAD LETTER QUEUE or discards it.
In this case, the Queue Remote has a RQMNAME which actually does not match the actual queue manager name (rather its an alias 'DXCL01') and hence the message arriving on destination Queue manager would have the RQMNAME as DXCL01 in the transmission header which would be different from actual queue manager name. How is receiver MCA handling this ?
Regards |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Jul 05, 2020 5:18 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| dextermbmq wrote: |
| But I am still unable to figure out on why having an Alias queue on Gateway Queue manager (and putting alias queue in the RNAME of Queue Remote) would not work. |
There is no RNAME attribute of a QAlias. Do you mean a 'queue-manager alias? Please be precise.
| dextermbmq wrote: |
| Another doubt (may be a silly one), I was of the view that the messages when sit on the transmission queue have a transmission header that carries the details of Remote Queue Manager and Remote Queue. The transmission header is validated by the Remote/Receiver Queue Manager MCA. |
"validated" is imprecise; rather, "name resolution." Every time MQ internals encounter a name, the "name resolution" process takes place. When a message arrives at the receiver end of a channel, the MCA will drive name resolution. It will ask "am I connected to the same queue-manager that is named in the XQH?" If not, it will drive name resolution to see if there is a local definition (QLocal, QModel, QAlias, QRemote) with that name to see if that definition resolves the name.
| dextermbmq wrote: |
| If the details of RNAME and RQMNAME is not correct receiver MCA either places the message on DEAD LETTER QUEUE or discards it. |
Yes.
| dextermbmq wrote: |
| In this case, the Queue Remote has a RQMNAME which actually does not match the actual queue manager name (rather its an alias 'DXCL01') and hence the message arriving on destination Queue manager would have the RQMNAME as DXCL01 in the transmission header which would be different from actual queue manager name. How is receiver MCA handling this ? |
Which Queue Remote? Where? On the originating qmgr? On the destination qmgr? XQH fields (remote queue name, remote qmgr name) are NOT resolved (validated, your terminology) on the sending side.
If a msg arrives on a cluster qmgr, it is possible that during name resolution, a clustered object definition will resolve a name. A clustered queue-manager alias (QRemote def without RName attribute) does this to move the msg further down the network, OR to correct an incorrect RQMname in an XQH.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live.
Last edited by bruce2359 on Sun Jul 05, 2020 5:26 am; edited 1 time in total |
|
| Back to top |
|
|
| exerk |
| Posted: Sun Jul 05, 2020 5:21 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| dextermbmq wrote: |
...But I am still unable to figure out on why having an Alias queue on Gateway Queue manager (and putting alias queue in the RNAME of Queue Remote) would not work.
Another doubt (may be a silly one), I was of the view that the messages when sit on the transmission queue have a transmission header that carries the details of Remote Queue Manager and Remote Queue. The transmission header is validated by the Remote/Receiver Queue Manager MCA. If the details of RNAME and RQMNAME is not correct receiver MCA either places the message on DEAD LETTER QUEUE or discards it.
In this case, the Queue Remote has a RQMNAME which actually does not match the actual queue manager name (rather its an alias 'DXCL01') and hence the message arriving on destination Queue manager would have the RQMNAME as DXCL01 in the transmission header which would be different from actual queue manager name. How is receiver MCA handling this ?
Regards |
Name resolution is the answer.
When a message arrives from a remote queue manager a number of things happen:
1. The receiving queue manager examines the message header, and asks itself the question "is it for me?".
2. If the answer to that is no, it then asks itself "do I have a reference to the RQMNAME?" and will look for either a transmission queue of that name, or other object of that name. If the queue manager does not have a reference to that name it will be rejected back to the sending queue manager, or go to the DLQ, or be discarded (dependent on channel settings and message persistence).
3. If the answer is yes, it will look for the RNAME object and put the message on the queue that matches the RNAME, or try to resolve the object elsewhere. In a queue manager cluster environment, where the receiving MCA is dealing with a message, it may be unable to do so.
And so back to number 2. above.
The RQMNAME, which is DXCL01 in the above example, is an alias so what happens is:
1. The gateway queue manager sees that the RQMNAME is not its own so looks for a reference to DXCL01;
2. It finds a reference (the QR) and sees that the RNAME, RQMNAME, and XMITQ values are empty, and says to itself "Aha! It's a cluster queue manager alias, and means that the message is for me to route somewhere else."
3. It will re-examine the message header for the RNAME within it and look for that object name in any cluster of which it is a member, and if it can resolve it, will forward the message to an instance of the queue.
It's one of those very, very clever features that the people at Hursley (all hail Hursley people!) built into the product.
And it's not a silly doubt, at all. Name resolution and routing can tie people in knots and can take a long time to get your head around, especially when using multiple hops.
It can be even more head-scratching when you have another layer of abstraction, e.g. third-party -> your external non-clustered gateway queue manager -> your internal clustered gateway queue manager -> clustered application queue manager, and back.
EDIT: And I see that Bruce beat me to the button whilst I was typing!
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Jul 05, 2020 5:28 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Bruce is on his 3rd cup of leaded coffee😎
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| exerk |
| Posted: Sun Jul 05, 2020 5:30 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| bruce2359 wrote: |
| Bruce is on his 3rd cup of leaded coffee😎 |
Lucky you! The "boss" limits me to one per day, before lunch, after which it has to be unleaded. 
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Jul 05, 2020 7:41 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
And don't forget the return path
On the gateway define:
| Code: |
def ql(target.xmitq) usage(xmitq) trigger initq(system.channel.initq)
def qr(target) rqmname(target) rname(' ') xmitq(target.xmitq) cluster('mycluster')
def chl(gatway.target) chltype(sdr) conname('target.target.com(port)') xmitq(target.xmitq)
|
Using the Remote queue and sharing it in the cluster allows you to have a default return path from the processing qmgr. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| exerk |
| Posted: Mon Jul 06, 2020 9:47 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Moved to the appropriate forum...
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| dextermbmq |
| Posted: Tue Jul 21, 2020 5:44 am Post subject: |
|
|
Voyager
Joined: 26 Jul 2014
Posts: 77
|
I guess a Thank You was pending from my end. Thanks  |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
