| Author |
Message
|
| paulfitz |
 Posted: Tue Jun 15, 2004 7:37 am Post subject: Reply To Q Names in a non clustered environment |
 |
|
Newbie
Joined: 15 Jun 2004
Posts: 8
|
I have picked up the support of an app as it moves into a production testing environment and have a question about reply to q names. In the dev test environments the code only has to a reply to a local queue definition and gets the q name to reply to from the reply to field in the request header and this works fine. However in production the reply q will actually be a remote q (this is in a non clustered environment). When we recieve the message in this environment the q name is as the requester see's it eg. BobsQ. I obviously do not have a BobsQ in my set up, I have my own remote q definition eg. PaulRemoteQ, that has in its properties a reference to BobsQ. When trying to access BobsQ I get a failure that it can't find that q (to prove that everything else works I have tested with a hard coded reference to PaulRemoteQ and this works). Does this method of keeping the reply to q in the header work in a non clustered environment (a colleague with more MQ experience than myself has only ever seen this method in clustered environments)? or is the api for accessing the q being used incorrectly (using JMS from Java and doing an QueueManager.accessQueue(), is there a method that recognises that I am after a remote q and not its name in this environment but as defined in its RName property)?
Thanks in advance,
Paul Fitz. |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Tue Jun 15, 2004 8:38 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
It works fine if your remote queue name is the same as the local queue name on the other end.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| bbburson |
| Posted: Tue Jun 15, 2004 10:10 am Post subject: Naming conventions |
|
|
Partisan
Joined: 06 Jan 2004
Posts: 378
Location: Nowhere near a queue manager
|
| Naming conventions are wonderful things. At our site we always name remote queues the same as the target local queue; we always name transmit queues the same at the target queue manager; we always name sender/receiver channels <FromQMgr>.<ToQMgr>. Saves a lot of confusion and it makes it easy for a new person to figure out what connects to what and where to look for messages. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Jun 15, 2004 10:24 am Post subject: Re: Naming conventions |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| bbburson wrote: |
| Naming conventions are wonderful things. |
I agree.
I keep waiting for one of the management tools to build in functions to allow you to support and audit naming standards compliance.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Heinz57 |
| Posted: Tue Jun 15, 2004 11:38 am Post subject: |
|
|
Apprentice
Joined: 21 Jan 2004
Posts: 26
Location: Syracuse, NY
|
| We usually use qalias in our local qmgr that resolves to the remote q. You could specify a qalias of Bobsq that points to Paulsremoteq that poits to Bobsq on another qmgr... Just our way of using reply to's when they're not in the cluster... |
|
| Back to top |
|
|
| tkane |
| Posted: Tue Jun 15, 2004 11:52 am Post subject: |
|
|
Voyager
Joined: 23 Dec 2002
Posts: 82
Location: Kansas City
|
In a distributed queuing application where an applciation sends a request message and properly fills in the md.ReplyToQ and md.ReplyToQMgr fields in the input message descriptor then a well behaved server applciation that reads these and honors them can get back to the original reply to queue without a qremote. That is if you name your transmit queues the same as your queue manager.
There is a sample on Unix called amqsreq0.c that shows how to do the request and look for a reply.
Also a sample triggered echo program called amqsecha.c
These can be run with a pair of channels and one queue remote that points to the queue that the echo program triggers on.
Good Luck
Tom |
|
| Back to top |
|
|
|
|
