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 » General IBM MQ Support » MQRC 2087 not able to resolve based on needs

Post new topic  Reply to topic Goto page Previous  1, 2
 MQRC 2087 not able to resolve based on needs « View previous topic :: View next topic » 
Author Message
PeterPotkay
PostPosted: Mon Jun 26, 2017 5:07 pm    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

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
View user's profile Send private message
smeunier
PostPosted: Thu Aug 17, 2017 12:16 pm    Post subject: Reply with quote

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
View user's profile Send private message
mqjeff
PostPosted: Thu Aug 17, 2017 1:33 pm    Post subject: Reply with quote

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
View user's profile Send private message
fjb_saper
PostPosted: Thu Aug 17, 2017 8:37 pm    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
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
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic  Reply to topic Goto page Previous  1, 2 Page 2 of 2

MQSeries.net Forum Index » General IBM MQ Support » MQRC 2087 not able to resolve based on needs
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.