| Author |
Message
|
| sebastia |
 Posted: Mon May 13, 2013 6:15 am Post subject: empty REPLYTOQMGR in request message |
 |
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Hi, coleagues.
My customer has a cluster where "external" clients, this is message providers, use MQ Client to write into a queue that is multi-instance defined in the MQ cluster.
All works fine, and messages are split between consumers.
Problem comes when we try to use Request-Reply model,
and the "ReplyTo" queue we want to be a cluster queue.
We write a message into the cluster, but the ReplyToQueueManager field comes up filled with the name of the queue manager where the MQ Client was connected when writing the message into the cluster.
In this scenario, the "consumer" queue manager has to have a specific channel to "origin" queue manager in order to deliver the response message, and we dont want that.
We are reading "configuring request/reply to a cluster"
>>> http://publib.boulder.ibm.com/infocenter/wmqv7/v7r1/index.jsp?topic=/com.ibm.mq.doc/qc10830_.htm
... but our scenario is a bit diferent, because there is not a queue manager "external" to the cluster, so queue manager alias can not be used.
Any ideas why ReplyToQueueManager field can not be empty ?
I mean, if we want the reply to come to a specific queue manager, we always can fill this field, but would like to leave it empty sometimes.
Sebastian. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Mon May 13, 2013 6:21 am Post subject: Re: empty REPLYTOQMGR in request message |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sebastia wrote: |
| I mean, if we want the reply to come to a specific queue manager, we always can fill this field, but would like to leave it empty sometimes. |
I'm slightly confused. In what kind of Request/Reply would you not want the reply to go to the requestor?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sebastia |
| Posted: Mon May 13, 2013 6:28 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Hi, Vitor.
Requestors are outside the cluster.
And the response shall go to where they select, if possible, to a cluster queue.
Again, if we want the response to come to a specific queue manager, we can fill the field, ans we get it there.
But, if we have a "centralized" pending responses manager ... we need to be able to leave this field empty, as we can have it duplicated for higher availability.
Thanks. Sebastian. |
|
| Back to top |
|
|
| hughson |
| Posted: Mon May 13, 2013 6:41 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
So i get the impression that this is more of a workflow than a request/response. The messages are not going back to the requester, they are just going on to some other queue?
Note that we do not recommend clustering replyToQs for the very reason that the reply messages are unlikely to come back to the intended recipient!
I don't know if this will work or not as I haven't tried it, but have you tried having a QREMOTE with a blank RQMNAME and the RNAME of the cluster queue and have them refer to that QREMOTE on a named queue manager as their ReplyToQ?
Cheers
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| sebastia |
| Posted: Mon May 13, 2013 6:47 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
The problem I see is not the model or the destination of the reply.
My problem is that we have a "pure" cluster environment,
where the queue managers only have a TO.FR cluster sender channel.
And now, in order to deliver the response,
it looks like we have to define (lots of) one-to-one old-style SENDER+RCVR channels.
See my point ? |
|
| Back to top |
|
|
| hughson |
| Posted: Mon May 13, 2013 6:54 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
Actually I don't understand your point about channels. I thought your problem was getting queue name resolution to find a cluster queue when you always had the ReplyToQMgr filled in.
Can you elaborate on why this problem means you have to define lots of non-clustered channels?
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| sebastia |
| Posted: Mon May 13, 2013 6:58 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
The problem with non-cluster channels is we told customer to live, to configure and work with cluster-only channels.
The main reason was not-to-have large number of channels defined, neither transmission queues, nor remote queues.
And we are doing fine until now.
Thanks. Sebastian. |
|
| Back to top |
|
|
| hughson |
| Posted: Mon May 13, 2013 7:18 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
I understand that you want to stick to only cluster channels. What I don't understand is why you think you need non-cluster channels for this issue?
Can you elaborate on that please?
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| sebastia |
| Posted: Mon May 13, 2013 7:33 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Yes, of course.
We try to set "ReplyToQueueManager" field blank in the request message.
In this way, the response can go to a cluster queue.
Am I right until now?
As the "source" of our message is a MQ client outside the cluster, and the client uses a code similar to "amqsecha.c", we find that the message written into the cluster queue has the "ReplyToQueueManager" filled with the name of the queue manager where the mq client was connected when writing the request message.
At this point I think the "cluster" queue can not be used .... as there is a specific queue manager where to send the reply message.
Next, if we want the reply message to reach its destination, the only way I know is to define a transmit queue, a sender channel, etc etc, which I would like not to do.
Sorry if my explanation is not good enough.
And thaks for your time.
Sebastian. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon May 13, 2013 7:39 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| hughson wrote: |
I understand that you want to stick to only cluster channels. What I don't understand is why you think you need non-cluster channels for this issue?
Can you elaborate on that please? |
So you have a non-cluster member queue manager sending "requests" into the cluster. If these result in a "response" which is not a reply to the original requestor but is more of a forwarded message to a 3rd destination which is a cluster location shared by 1-n queue managers which will see this new message load balanced across the cluster in the traditional way.
Assuming I have this correct (which is a big assumption I accept):
- why call this request / reply?
- why not simply blank out the ReplyToQmgr for those classes of message which fall into the category above, either when the request is produced or when the responder determines this needs to be done?
- what do channels, cluster or not, have to do with any of this?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| hughson |
| Posted: Mon May 13, 2013 7:42 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
OK - perhaps it is worth pointing out at this moment, that you can put to a fully-qualified queue (that is one where you specify both the queue and the queue manager name) and have that message delivered to a remote queue manager over cluster channels. There is no need to define non-cluster channels in order to deliver such a message and this includes whether that queue is clustered or not clustered (e.g. the standard reply queue model that you are not using). The only requirement is that the queue manager is known to the cluster, i.e. by being a member of the cluster.
In your case you have a real queue manager name being written in the ReplyToQMgr field of the MQMD so the cluster channels will be able to deliver the message to that queue manager. The only time you would need to define non-cluster channels is if you are trying to deliver the message to a queue hosted by a queue manager that is not a member of the cluster. I don't get the impression from what you say that you are trying to do this?
So I believe you don't need any non-cluster channels and what you are actually trying solve is a queue name resolution problem as per my original suggestion.
Have I missed something?
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon May 13, 2013 7:47 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sebastia wrote: |
| As the "source" of our message is a MQ client outside the cluster, and the client uses a code similar to "amqsecha.c", we find that the message written into the cluster queue has the "ReplyToQueueManager" filled with the name of the queue manager where the mq client was connected when writing the request message. |
That's certainly the default behaviour where the client doesn't explicitly provide a queue manager name. It could equally provide an explicit blank or explicitly name the cluster as the reply to queue manager.
| sebastia wrote: |
| At this point I think the "cluster" queue can not be used .... as there is a specific queue manager where to send the reply message. |
Only if the responding application blindly uses the reply to queue manager name. There's nothing within WMQ enforcing that. It's at liberty to use any queue manager name or none.
| sebastia wrote: |
| Next, if we want the reply message to reach its destination, the only way I know is to define a transmit queue, a sender channel, etc etc, which I would like not to do. |
If the responder is outside the cluster then you'll need all of these good things someplace, and something that permits resolution. If you're sending within the cluster you just need resolution.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon May 13, 2013 12:08 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Have the putting application, the psuedo requester, specify the real reply queue name in the Reply To Queue field of the MQMD of the 'request' message, and fill in the Reply To QM field with a value called VITOR_WUZ_HERE, or any other value you like. Just don't leave it blank or don't fill it in with the name of a real QM.
The message will arrive at the 'replying' app with the reply to queue field filled in with the real reply q name, and the Reply To QM filled in with VITOR_WUZ_HERE. When the app 'replies', it opens the the reply queu specifying both the destination queue (the real reply q) and the destination QM (VITOR_WUZ_HERE).
Insure there is a QM Alias called VITOR_WUZ_HERE that routes messages to an XMITQ that gets you back to a Queue Manager in the cluster. I'm assuming the replying app is connected to a QM outside the cluster. On the QM in the cluster that has the RCVR channel from the QM outside the cluster create a QM Alias called VITOR_WUZ_HERE that has a blank Remote Q, blank Remote QM Name and blank XMITQ attribute. As messages arrive destined for a QM called VITOR_WUZ_HERE, this alias will blank out the destination QM and MQ name resolution kicks in looking for that reply queue without a specific QM, and the message will load balance inside the cluster.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon May 13, 2013 12:42 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| PeterPotkay wrote: |
| VITOR_WUZ_HERE |
No I wuzn't....
An eloquent and elegant solution.  
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon May 13, 2013 8:05 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
To add to this gently:
Assuming your outside requester connects to your cluster through either of 2 gateway qmgrs...
On those 2 gateway qmgrs you need a default name resolution for the requesting qmgr (complete with xmitq and p2p channel). For the xmitq do not use the destination qmgr name but use something like qmgr.xmitq. Then create a QRemote as an Alias for the remote qmgr (outside the cluster) and share this alias in the cluster.
Now from anywhere in the cluster you can route to the external qmgr going through your gateway(s) where you defined the shared alias to the cluster.
The P2P channel to the requester need only be defined on your gateway qmgr...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
