| Author |
Message
|
| sebastia |
 Posted: Tue May 14, 2013 1:56 am Post subject: |
 |
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
| Vitor wrote: |
| So you have a non-cluster member queue manager sending "requests" into the cluster. |
Not exactly - the origin of messages is a machine with MQ Client in it.
But it has no queue manager. |
|
| Back to top |
|
 |
| sebastia |
| Posted: Tue May 14, 2013 2:12 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
| Vitor wrote: |
| - why not simply blank out the ReplyToQmgr for those classes of message which fall into the category above |
Vitor : this is exactly what we are trying to do - specify blank ReplyToQmgr.
But it seems not possible.
Ths field is filled up with the name of the queue manager where the MQ client is connected.
Then, the response is not using clustering anymore. |
|
| Back to top |
|
|
| sebastia |
| Posted: Tue May 14, 2013 2:17 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
| Vitor wrote: |
| 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. |
Well, the responder application uses whatever data it is provided.
And I think it is good to work in a clear way :
Shall the origin privide a ReplyToQmgr, then use it.
If origin does not, use blank qmgr name, so clustering come into play.
My problem is ReplyToQmgr field I provide is blank, but message gets a name written into it. |
|
| Back to top |
|
|
| sebastia |
| Posted: Tue May 14, 2013 2:23 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
| hughson wrote: |
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 : if the ReplyToQmgr field is not empty, the clustering (workload balancing) is not used.
Message is delivered to a specific queue manager.
But this is not the case I am trying to work in : I provided an EMPTY ReplyToQmgr field
And we want the message to keep this characteristic, so reply uses cluster resolution
Resum or question change :
>>> how can I set a blank ReplyToQmgr field in a message sent into a cluster using MQ client ?
Thanks. Sebastian. |
|
| Back to top |
|
|
| hughson |
| Posted: Tue May 14, 2013 3:09 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand
|
| sebastia wrote: |
Morag : if the ReplyToQmgr field is not empty, the clustering (workload balancing) is not used.
Message is delivered to a specific queue manager. |
The workload balancing algorithm is not used to choose an instance of the queue in this case as the instance is pre-chosen by providing the queue manager name, however, clustering is still used to deliver the message across cluster channels. You do not need to define non-cluster SDR/RCVR channels.
| sebastia wrote: |
| >>> how can I set a blank ReplyToQmgr field in a message sent into a cluster using MQ client ? |
Did my earlier suggestion work?
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| sebastia |
| Posted: Tue May 14, 2013 4:19 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Hi again, Morag.
Guess with your "earlier suggestion" you mean this phrase :
| Quote: |
| 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. |
Then I have to say "yes, it works".
But what we try to do is
a) to write a ReplyToQueue into the request message
b) NOT to specify a ReplyToQueueManager
We do not want the response message to come to this "entry" queue manager.
We want to set this field BLANK, so someone in the cluster will define this object and the response shall go there.
Is this possible ?
Sebastian. |
|
| Back to top |
|
|
| hughson |
| Posted: Tue May 14, 2013 4:30 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand
|
Actually no, I meant this...
| hughson wrote: |
| 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? |
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| sebastia |
| Posted: Tue May 14, 2013 4:59 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
I shall try it within minutes
A schema I have is :
| Code: |
.---------------------------.
| |
| .-------.
.--------. .-------. | p7029 |
| MQ | | | .-------.
| client | ------- | PATAN | |
| T400 | | | .------.
.--------. .-------. | QMAS |
| .------.
| |
| .-------. .------. |
.---| CLFR1 |----| CLF2 |---.
.-------. .------.
|
In qmgr QMAS, where request message shall be received, I shall define
| Quote: |
| DEFINE QREMOTE(QR.MH) RNAME(QL.RSP) RQMNAME(' ') |
And in p7029, where response message is suposed to be received, I shall define
| Quote: |
| DEFINE QLOCAL(QL.RSP) CLUSTER(SAGCLUSTER) |
The message sent from T400 into the cluster shall be addressed to QL.IN (cluster queue, defined in QMAS), with
ReplyToQueue(QR.MH)
and
ReplyToQmgr(' '), but this field will be changed by MQ into "PATAN"
Sebastian. |
|
| Back to top |
|
|
| sebastia |
| Posted: Tue May 14, 2013 5:54 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Well, MQ works as designed :
We send a message with ReplyToQueue = QR.MH
and ReplyToQmgr = " "
MQ client connects to queue manager "PATAN" ...
At QMAS the "responder APP" uses MQPUT1() :
| Quote: |
>>> Put1() a msg. hCon [0x104168e0].
Q
[QL.RSP ],
qmgr
[PATAN ].
+-+ MQPUT1() CC/RC [0x02/0x0827] {MQRC 2087}.
|
This is, QR.IN has been resolved into QL.RSP,
but PATAN (queue manager name) is still there,
so the cluster queue is not visible
(QL.RSP exists only at QMAS queue manager),
and we get MQRC=2087, MQRC_UNKNOWN_REMOTE_Q_MGR |
|
| Back to top |
|
|
| hughson |
| Posted: Tue May 14, 2013 6:49 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand
|
|
| Back to top |
|
|
| sebastia |
| Posted: Tue May 14, 2013 6:53 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
EXACTLY ! I need RQMNAME=' ' ;
I dont understand why queue manager sets ReplyToQmgr field
when AMQSREQC.exe (MQ client code) is used
and sends a "blank" ReplyToQmgr field |
|
| Back to top |
|
|
| hughson |
| Posted: Tue May 14, 2013 7:20 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand
|
Because that is what it is designed to do. It is not designed for reply Queues to be clustered. This is why you have to follow the instructions in that link (with the minor change of RQMNAME(' ') at the correct point).
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| sebastia |
| Posted: Tue May 14, 2013 7:29 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
OK; if it is a DESIGN issue, I cant fight against it.
Just for the knowledge :
? can you provide a pointer to where this sentence can be found ?
Something like ... "reply queues can not be clustered"
By example, this link
>>> http://publib.boulder.ibm.com/infocenter/wmqv7/v7r1/index.jsp?topic=%2Fcom.ibm.mq.doc%2Ffa10440_.htm
says ...
| Quote: |
Reply-to queues
When an application sends a request message, the application that receives the message can send back a reply message to the sending application. This message is put on a queue, called a reply-to queue, which is normally a local queue to the sending application. The name of the reply-to queue is specified by the sending application as part of the message descriptor. |
Nothing about the impediment ...
Thanks. |
|
| Back to top |
|
|
| hughson |
| Posted: Tue May 14, 2013 7:53 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand
|
It's not a must not, just a recommendation. As you'll see when you follow the instructions, it can be done, but not so easy as using the best practice.
The product is designed to help you do the right thing. The right thing is to have the reply come back to where the application is. Since you don't want that, you are working against the way the product was designed.
As was noted when you started this thread, you are not doing request/reply, you are using the replyQ as a "forward the message onto the next guy" queue.
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue May 14, 2013 8:08 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
sebastia, did you see my previous reply? Would that work for you?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
