| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| How does one control COA return channel activation? |
« View previous topic :: View next topic » |
| Author |
Message
|
| extrospect |
 Posted: Fri Feb 27, 2004 2:15 pm Post subject: How does one control COA return channel activation? |
 |
|
Newbie
Joined: 27 Feb 2004
Posts: 2
|
Scenario: Sending a message to a remote target. Requesting COA.
API: I've used the Koban .NET library. I supply a COA queue, leave the COA queue manager blank, and it (or the lower API layer) supplies the COA queue manager name.
I've played with this quite a bit. In practice, if the remote queue manager has an empty default transmission queue, my COAs go to SYSTEM.DEAD.LETTER.QUEUE on the remote machine. If I have defined a transmission queue, then I get my message back. But of course, I don't want to rely on a remote company's default transmission queue!
Observations: Name resolution is remotely based on queue manager name and queue name. Both have been supplied with message. Since QM name is supplied, it appears to use the default transmission queue rather than attending to any alias or remote queue definition I have set up.
Questions:
1. Is it true that QM name must be supplied with a COA?
2. If QM is supplied, does that mean (remote) queue name resolution will always forego alias & remote queue definition?
3. Does ignoring alias & remote queue definition (on the remote queue manager) mean that only default transmission queue can be used for the remote queue manager?
4. If the QM's default transmission queue used, does that mean that all COAs which hit the remote QM go to the same transmission queue, can only wake up a single channel (triggering functionality), and therefore can only ensure reply over a channel to a single counterparty?
If all answers are YES, then that means that my reply to message can not easily wake up a return channel back to me. Except in the case where there is a dedicated "default transmission queue" back to me, which really means that one would configure the system with a queue manager for each distinct counterparty who might want COAs/CODs.
5. How do programmers think about automatic return channel activation in practice?
6. Do programmers build applications which await COA, and hence rely upon automatic return activation from remote partners?
Thank you,
Mark |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Sat Feb 28, 2004 11:04 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Quote: |
API: I've used the Koban .NET library.
|
You should download CSD05 or CSD06 for MQ5.3. Or the latest MQClient, which includes CSD05 (and then aply CSD06 to that). They include official versions of the .NET interface, fully supported by IBM. CSD06 has lots of fixes for the.NET classes.
| Quote: |
1. Is it true that QM name must be supplied with a COA?
|
If you are on QM1 and you send the request to QM2, QM2 needs to know where to send the COA to. So yes, you (or more properly, QM2) needs the Reply To Queue Manager name.
| Quote: |
2. If QM is supplied, does that mean (remote) queue name resolution will always forego alias & remote queue definition?
|
Yes.
| Quote: |
3. Does ignoring alias & remote queue definition (on the remote queue manager) mean that only default transmission queue can be used for the remote queue manager?
|
No. The default XMIT queue is the last resort for name resolution when a QM name is supplied on the MQOPEN. It will first check to see if it is the local QM, then if there are any XMIT queues by that name, then if there are any QMAliases by that name, then if there any Cluster Queue Managers by that name if the local QM is in a cluster, and then finally the default is used. You should go to the Index of the App Prog Guide, and look up "Name Resolution".
| Quote: |
4. If the QM's default transmission queue used, does that mean that all COAs which hit the remote QM go to the same transmission queue, can only wake up a single channel (triggering functionality), and therefore can only ensure reply over a channel to a single counterparty?
|
Look at the answer to number 3. If none of those other methods are there, then yes, this is true.
| Quote: |
5. How do programmers think about automatic return channel activation in practice?
|
They shouldn't have to, if the MQ admin set up a return channel and transmit queue back to your QM.
| Quote: |
6. Do programmers build applications which await COA, and hence rely upon automatic return activation from remote partners?
|
Yes, but the underlying infrastructure needs to be there.
| Quote: |
If I have defined a transmission queue, then I get my message back. But of course, I don't want to rely on a remote company's default transmission queue!
|
You are not relying on their default transmit queue. You are relying that there is A transmit queue back to your QM. It can but does not have to be the default transmit queue for them.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| 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
|
|
|
|
