ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » Clustering » Can Remote Queue pointing to Alias Q

Post new topic  Reply to topic
 Can Remote Queue pointing to Alias Q « View previous topic :: View next topic » 
Author Message
dextermbmq
PostPosted: Sat Jul 04, 2020 5:55 am    Post subject: Can Remote Queue pointing to Alias Q Reply with quote

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
View user's profile Send private message
exerk
PostPosted: Sat Jul 04, 2020 12:22 pm    Post subject: Reply with quote

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
View user's profile Send private message
dextermbmq
PostPosted: Sun Jul 05, 2020 4:43 am    Post subject: Reply with quote

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
View user's profile Send private message
bruce2359
PostPosted: Sun Jul 05, 2020 5:18 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
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
View user's profile Send private message
exerk
PostPosted: Sun Jul 05, 2020 5:21 am    Post subject: Reply with quote

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
View user's profile Send private message
bruce2359
PostPosted: Sun Jul 05, 2020 5:28 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
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
View user's profile Send private message
exerk
PostPosted: Sun Jul 05, 2020 5:30 am    Post subject: Reply with quote

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
View user's profile Send private message
fjb_saper
PostPosted: Sun Jul 05, 2020 7:41 am    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
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
View user's profile Send private message Send e-mail
exerk
PostPosted: Mon Jul 06, 2020 9:47 am    Post subject: Reply with quote

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
View user's profile Send private message
dextermbmq
PostPosted: Tue Jul 21, 2020 5:44 am    Post subject: Reply with quote

Voyager

Joined: 26 Jul 2014
Posts: 77

I guess a Thank You was pending from my end. Thanks
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » Clustering » Can Remote Queue pointing to Alias Q
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.