| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| MQRC 2087 not able to resolve based on needs |
« View previous topic :: View next topic » |
| Author |
Message
|
| PeterPotkay |
 Posted: Mon Jun 26, 2017 5:07 pm Post subject: |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| smeunier wrote: |
| Quote: |
| Are the "1" queue managers in one cluster, the "3" queue managers in another cluster, and QMGR2 in both clusters? |
Yes, the "1" Queue managers are in one cluster and the "3" Queue managers are in another cluster. QMGR2 is a member of both clusters. So QMGR2 is in overlapping clusters. I think the easy solution is somewhere embedded in that fact. there are two clusters on either side of QMGR2, one for test environment and one for PROD environment. So in reality, there are 4 cluster that QMGR2 is involved in. The Queue names are the same for all qmgrs. So message affinity(to the reply2qmgr) must be maintained through the cluster. |
The way I would solve this is to create Queue Manager Aliases on QMGR2, shared in both clusters.
On QMGR2 create a QM Alias called MY_QMGR1a, that resolves the QM Name to QMGR1a.
On QMGR2 create a QM Alias called MY_QMGR1b, that resolves the QM Name to QMGR1b.
Now if an app connected to QMGR3a MQOPENs/MQPUT1s a message to THE.REPLY.QUEUE on MY_QMGR1b, the QM Alias on QMGR2 will "catch it", flip the destination QM name from MY_QMGR1b to QMGR1b, at which point the real QMGR1b catches the message and the message arrives in THE.REPLY.QUEUE.
So, how to get request messages to be sent with MQMD_ReplyToQueue set to THE.REPLY.QUEUE and the MQMD Reply To QM set to MY_QMGR1b if leaving from MY_QMGR1b? Use the rarely used ReplyTo Alias definition. Search for it in the manuals. On QMGR1b you create a Remote Queue Definition called MY.AWESOME.REPLY.QUEUE, and set its remote queue to THE.REPLY.QUEUE and its remote queue manager to MY_QMGR1b. Do the same on QMGR1a, except set the remote queue manager name to MY_QMGR1a. Now when your requesting app sets its MQMD Reply To Queue, it sets it to MY.AWESOME.REPLY.QUEUE, and it gets to leave the MQMD Reply To Queue Manager blank, which is ideal. But the request message gets sent with the real reply to queue (THE.REPLY.QUEUE) and the reply to queue manager set to MY_QMGR1b (or a). What's happening is the ReplyTo Alias intercepts the put of the request message and tweaks the MQMD's Reply To info to your desired values. Whoa, powerful stuff! Your requesting app doesn't have to keep track of funky reply to queue manager names, it gets to leave the MQMD Reply To QM field blank on its puts. Yet the request messages it produces have the reply to details you need. No need for any definitions on QMGR3a and QMGR3b, no need for them to even know the real #1 QM names. Obfuscate the names as much as you need.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
 |
| smeunier |
| Posted: Thu Aug 17, 2017 12:16 pm Post subject: |
|
|
Partisan
Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont
|
Circling around on this again as it is still not fully functional the way it needs to be. I was able to get the name resolution to work for the replies, but further test showed that all replies were sent to the same queue manager and not the QMGR in the ReplyToQMGR field of the message header.
To restate the problem in simpler terms:
Qmgr1a Qmgr3a
GW QMGR2
Qmgr1b Qmgr3b
Qmgr1a/b are in a cluster(CLUSMES) and Qmgr3a/b are in a Cluster(CLUSHUBS)
QMGR2 is in both clusters
Qmgr1a/b send request to QR Alias which is gateway to cluster CLUSHUBS for load balancing between the two active Qmgr3a/b (This works greaat)
Qmgr3a/b needs to respond back to the originating Qmgr1a/b that initiated the request. The Request Queues are clustered. The reply queues are not clustered but could be if it would make this all simpler.
I have defined a Remote QMGR Alias on QMGR2 for Qmgr1a(just trying one at this point) to CLUSHUBS as such:
DEFINE QREMOTE('QMGR1A') +
CLUSTER(CLUSHUBS) +
RQMNAME('QMGR1A') +
RNAME(' ') +
XMITQ('QMGR1A.X') +
REPLACE
Notice, for this, I'm not using cluster channels to deliver but standard channels back to Qmgr1a/b
On QMGR3A/B there is a reply queue definition for the ReplyToQueue
DEFINE QREMOTE('REPLY_TO_QUEUE') +
RQMNAME('') +
RNAME(' ') +
XMITQ('QMGR2.X') +
REPLACE
With this, I'm back to: MQ2087 MQRC_UNKNOWN_REMOTE_Q_MGR
The Options on the PUT for the reply are:
options = MQOO_ALTERNATE_USER_AUTHORITY | MQOO_OUTPUT | MQOO_FAIL_IF_QUIESCING | MQOO_BIND_AS_Q_DEF | MQOO_SET_IDENTITY_CONTEXT
I thought the QR Alias to the replytoQmgr defined to the CLUSHUBS queue mgr would resolve the issue, but maybe I only have half the solution. I have tried to search for a concrete example on this in documentation, but the examples are vague and not complete. I only need to solve the Reply portion of this.
Can the gateway QMGR resolve this? Can it only do it via clustering?
- Should this be solved at the cluster level even though the ReplyToQueue on Qmgr1a/b does not need to be clustered? With an implied Message Affinity to the ReplyToQmgr this seems unnecessary, but may be an easier solution.
The replyToQmgr is not in the same cluster as the Reply/connecting application.
I would actually like to solve this in a non-cluster methodolgy if possible and reserve the cluster only for Load balancing. I thought I had resolved it, until I sent a message in from a different QMGR(Qmgr1b) and it ended up going to Qmgr1a, event though the ReplyToQmgr was Qmgr1b.
As always thanks in advance for any guidance. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Aug 17, 2017 1:33 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
First thing to make sure is that the replying application actually uses the RepllyTo fields of the mqmd...
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Aug 17, 2017 8:37 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| smeunier wrote: |
On QMGR3A/B there is a reply queue definition for the ReplyToQueue
DEFINE QREMOTE('REPLY_TO_QUEUE') +
RQMNAME('') +
RNAME(' ') +
XMITQ('QMGR2.X') +
REPLACE
As always thanks in advance for any guidance. |
This is where the error lies. Delete this definition. All it does is muddy the waters.
The qmgr alias on QM2 are shared in the cluster and standard cluster channels will be used to move the message from qmgr3(a/b) to qmgr2.
On qmgr2 the message will be redirected to their respective destination using the channels using the xmitq defined in the respective alias.
The assumption here is of course that the app on qmgr3 (a/b) puts the message to the reply to queue and reply to queue manager in the request MQMD.
Use dspmqrte -t high -v all to see the path the response message will take when you put it to qmgr3 (a/b)
Now if you want to avoid using the cluster channels at all from qmgr3(a/b) to qmgr2 you need to define a qmgr alias for each of the my_qmgr1 (a/b) on each of the qmgr3 (a/b) specifying the xmitq for the channel to qmgr2.
The golden rule here is, that wherever you are, you need to have a default routing to the next hop/qmgr in the chain ...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
