| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| ReplyToQmgr Values |
« View previous topic :: View next topic » |
| Author |
Message
|
| splaaat |
 Posted: Thu Dec 18, 2008 5:02 am Post subject: ReplyToQmgr Values |
 |
|
Novice
Joined: 28 Apr 2007
Posts: 10
Location: UK
|
Hi Folks,
Could somebody please clear up some confusion I have over the setting of the ReplyToQmgr field in the MQMD.
I have looked at several sources of information, MQ Admin Manual, Application Programming Guide, Application Programming Reference, Intercommunications Manual and the MQ Clusters Manual as well as a large portion of the 65 pages of threads that reference 'ReplyToQMgr' on this site and I think I've just fried my brain. 
From what I have read, my perception is that there is never a situation where an application issuing a 'get' request on a queue will receive a message with an empty ReplyToQmgr field in the MQMD. I believe that, depending on the ReplytoQ field value, either the local Qmanager where the message was 'put' or the recipient Qmanager where the 'get' is requested manipulates the ReplyToQmgr after considering the value of the ReplyToQ field.
The reason for my request is that we have a problem with messages in a clustered Q setup where an app preserves the value of ReplyToQmgr and ReplyToQ from messages it 'get's and uses them to build the header for messages 'put' in reply after it has processed the original.
The setup is fairly convoluted and I can explain the circumstance if required, but I didn't want to produce a huge initial post if the answer to my confusion is "the ReplyToQmgr field will never be blank when a 'get' is issued against a queue".
Any help will be greatly appreciated 
The Splaaat  |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Dec 18, 2008 5:18 am Post subject: Re: ReplyToQmgr Values |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| splaaat wrote: |
| From what I have read, my perception is that there is never a situation where an application issuing a 'get' request on a queue will receive a message with an empty ReplyToQmgr field in the MQMD. I believe that, depending on the ReplytoQ field value, either the local Qmanager where the message was 'put' or the recipient Qmanager where the 'get' is requested manipulates the ReplyToQmgr after considering the value of the ReplyToQ field. |
Not quite. If the local queue manager has a message "put" on it where the ReplyToQmgr has been left blank, it will insert it's own name. If the field is not blank, the queue manager does not modify it (or check it). The remote queue manager can do nothing with this field, as it has no idea where the message originated.
I've never tried deliberately moving spaces to this field, then putting the message. I'd hope that you'd still get the local qm name, but can't vouch for that. Quick experiement will show that.
| splaaat wrote: |
| The reason for my request is that we have a problem with messages in a clustered Q setup where an app preserves the value of ReplyToQmgr and ReplyToQ from messages it 'get's and uses them to build the header for messages 'put' in reply after it has processed the original. |
More details of your problem may yield more advice.
| splaaat wrote: |
| if the answer to my confusion is "the ReplyToQmgr field will never be blank when a 'get' is issued against a queue". |
I'd be surprised to find the field blank.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| splaaat |
| Posted: Thu Dec 18, 2008 5:13 pm Post subject: |
|
|
Novice
Joined: 28 Apr 2007
Posts: 10
Location: UK
|
Hi Vitor,
Thanks for the reply.
| Quote: |
| Not quite. If the local queue manager has a message "put" on it where the ReplyToQmgr has been left blank, it will insert it's own name. If the field is not blank, the queue manager does not modify it (or check it). The remote queue manager can do nothing with this field, as it has no idea where the message originated. |
The main reason for my perception is this line from the Application Programming Reference describing the ReplyToQMgr field:
"If the ReplyToQMgr field is blank, the local queue manager looks up the ReplyToQ name in its queue definitions. If a local definition of a remote queue exists with this name, the ReplyToQMgr value in the transmitted message is replaced by the value of the RemoteQMgrName attribute from the definition of the remote queue, and this value is returned in the message descriptor when the receiving application issues an MQGET call for the message.
If a local definition of a remote queue does not exist, the ReplyToQMgr that is transmitted with the message is the name of the local queue manager."
I realise I've probably only seen a narrow view of the use of this field.
| Quote: |
| More details of your problem may yield more advice. |
I didn't want to subject you to this, but here goes 
Scenario:
The system in question is a low latency 24/7 operation which uses multiple instances of servers and MQ clustering to provide 'put' resilience.
We have 2 gateway devices (software applications on dedicated hardware) that mediate message flow between our internal systems and an external proprietory messaging system. MQ is used to deliver messages to and recieve messages from the gateways internally.
Externally originated messages are passed to and processed by either of 2 groups of processing servers (currently 4 servers per group) via clustered queues and responses are sent back to clustered queues on the gateways.
Internally originated messages are created by either of the 2 groups and sent to the gateways. Responses from the gateways must be sent back to a server in the originating group because the 2 groups do not share processing information.
We don't use any of the inherent MQ message reply or reporting mechanisms, each leg of the message flow as far as MQ is concerned is one-way. Relevent data from the MQMD and Message body is preserved by the applications on the gateways and processing groups which 'get' the original message. This is then used to build the MQMD for a response message once processing is complete.
All internal queues are clustered, all servers have a QManager installed, all apps work in Local Bindings mode.
I hope that makes sense.
Problem (I think):
Provided they are not blank, the application on the gateways uses the values in the ReplyToQ and ReplyToQmgr fields in the MQMD of the original message to address responses back to the relevent processing group. I believe messages addressed in this way get routed directly to the QManager/Queue combo, by-passing the cluster workload mechanism and negating any benefit gained from clustering. 
We have seen behaviour from the cluster that could have been caused by this when QMangers are taken offline for maintenance (messages waiting in the cluster transmission queue on the gateway for a QM that the cluster knows has been taken off line via suspension or 'put' disablement).
I think I need to convince the vendor of the gateway that his application should not be addressing the response messages with a QManager name, just the original ReplyToQ so the cluster mechanism ensures it goes to a 'live' QManager.
The vendor has stated that if there is a value in the ReplyToQmgr field it will be used, in conjunction with the ReplyToQ, to build the address for the reply message. If we don't want a value to be used, he has advised we set the field to be blank.
None of the applications on the processing servers manipulate the ReplyToQmgr field, so whatever value ends up in the MQMD by the time the gateway application 'get's the message is as a result of any default action taken by MQ in routing/resloving the message destination. I'm not sure that even if the applications were amended to set the ReplyToQmgr field to be blank before 'put'ing the message it would stay that way.
Would you agree that this is an issue and that not using the ReplyToQmgr value is a solution?
Thanks in anticipation. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Dec 18, 2008 11:50 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Quote: |
| Provided they are not blank, the application on the gateways uses the values in the ReplyToQ and ReplyToQmgr fields in the MQMD of the original message to address responses back to the relevent processing group. I believe messages addressed in this way get routed directly to the QManager/Queue combo, by-passing the cluster workload mechanism and negating any benefit gained from clustering. |
Not necessarily. Imagine both gateway qmgrs having defined remote qmgr aliases as clustered queues. Now the replies can be balanced through the gateways.
| Quote: |
We have seen behaviour from the cluster that could have been caused by this when QMangers are taken offline for maintenance (messages waiting in the cluster transmission queue on the gateway for a QM that the cluster knows has been taken off line via suspension or 'put' disablement).
I think I need to convince the vendor of the gateway that his application should not be addressing the response messages with a QManager name, just the original ReplyToQ so the cluster mechanism ensures it goes to a 'live' QManager. |
Depends whether the requesting app is in Request / reply mode or request and asynchronous load balanced reply processing. In the latter case a cluster qmgr alias can be substituted for the real one.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Dec 19, 2008 12:58 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Couldn't have said it better myself
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Dec 19, 2008 4:22 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| splaaat wrote: |
I think I need to convince the vendor of the gateway that his application should not be addressing the response messages with a QManager name, just the original ReplyToQ so the cluster mechanism ensures it goes to a 'live' QManager.
The vendor has stated that if there is a value in the ReplyToQmgr field it will be used, in conjunction with the ReplyToQ, to build the address for the reply message. If we don't want a value to be used, he has advised we set the field to be blank.
|
The vendor is coding their app correctly for once. What you need to do is start using ReplyTo Queue Aliases, a rarely used feature of MQ. The ReplyTo Queue Alias can make it so the Reply To QM field of your request messages has any value you want (not sure if blank is allowed, easy for you to test). But you can add the name of your cluster in that field, and define QM Aliases if they don't already exist that take a message addressed to the cluster and wipe out the destination QM name to blank.
By using ReplyTo Q Aliases, you can / should have different cluster names in your testing environments and the app's code does not need to change as it migrates.
Or you can hard code the cluster name into the ReplyToQM field at MQPUT time of the request message (you still need the QM Aliases either way).
Again, the vendor code is good. You need to make a minor change, not them. (Did I actually just say that?! )
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| splaaat |
| Posted: Sat Dec 20, 2008 4:02 am Post subject: |
|
|
Novice
Joined: 28 Apr 2007
Posts: 10
Location: UK
|
Hi Guys,
Thanks for the replies.
| Quote: |
| Depends whether the requesting app is in Request / reply mode or request and asynchronous load balanced reply processing |
Communication between the gateways and the external system is synchronous, but the connection to our internal MQ system is not. Messages have to be processed internally within a certain time frame or the external connection times out and the gateway sends a reverse of the original message. So we're not operating in a Request/Reply mode, more like a loadbalanced request /loadbalanced reply post processing mode. 
I'll see if I can get my head around the recommendations that have been made here (I'm fairly new to MQ) and have a bit of an experiment.
Before I run off and start to play, will any of this re-jigging of the ReplyToQmgr alter the way reporting works? There is a possibility that we may need to implement reporting so we can track individual messages through the system. I'd hate to paint myself into a corner.
Thanks again for the assistance, I think I'll be back. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Dec 20, 2008 9:09 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
You already have painted yourself into a corner. The fact that the gateway returns a time out forces you to send the reply to the requesting gateway. Now if you have 2 gateways and a clustered qmgr alias instance on both, when the requesting gateway goes down the reply could still go via the other gateway... However you are doing a 2 step process: client->requesting.gateway->server and server->requesting.gateway->client.
In that configuration you have a single point of failure: the requesting gateway.
I hope you have it hardware clustered.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Dec 20, 2008 11:32 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| If the (ReplyToQmgr) field is not blank, the queue manager does not modify it (or check it). |
(or check it).
Hmmm. IIRC, the sending qmgr does name resolution on both ReplyToQueue and ReplyToQmgr fields. If the requesting application doesn't populate the ReplyToQueue, the sending qmgr fills this field with its own name. If either names fail name resolutoin,, the MQPUT fails.
The replying application relies on these two fields to return the reply message to either the requesting application (the usual synchronous request-reply model) or to a third qmgr (asynchronous model). Think of a remote qmgr where the replying application executes. The remote qmgr can not resolve the name of the ReplyToQueue (think of a dynamic queue name with the * naming rule).
The replying application also relies on the ReplyToQmgr name field, since it is this name that must eventually map to an xmit queue at MQOPEN or MQPUT1 for the return trip. The ReplyToQmgr name field is also used at the replying qmgr to populate the XQH; which, the receiving MCA at the requesting qmgr must resolve to the requesting qmgrs name.
_________________
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 |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
