| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| MQ series log |
« View previous topic :: View next topic » |
| Author |
Message
|
| kevinf2349 |
 Posted: Thu Sep 16, 2004 5:13 am Post subject: |
 |
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| The transmit queue is what ties the remote queue definition to the channel. |
|
| Back to top |
|
 |
| Nigelg |
| Posted: Thu Sep 16, 2004 5:15 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
| A remote queue contains an XMITQ attribute, so the channel which is using the xmitq is the one that the msg will flow down. If the XMITQ attribute is not defined, the RQMNAME attribute is used to match the xmitq on a channel. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Sep 16, 2004 9:33 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
| csmith28 wrote: |
If your MQManager has a relationship with a remote MQManager setting up separate SDR/RCVR channel pairs and XMITQ's eliminates a possible single point of failure.
Further if you document what channels and queues belong to what applications and you start having problem you will know which application is having problems.
I walked into a real mess in my current position where one of my adopted MQManagers is serving roughly sixteen hi-volume production applications with a single XMITQ SDR/RCVR RCVR/SDR set and this has caused........ problems. |
I don't know that I agree with this, although it certainly works.
The manual (or was it a session at the conferance?) clearly states that 2 channels will not perform better than one channel carrying double the load.
The only valid reasons I can think of for different channels is:
1. Big messages versus small messages. You don't want the realtivly slow transmission of 50 MG messages corking up the channel while little messages are waiting.
2.Batch channels. You dont want a batch app with no timely sycronous requirements to dump 100,000 messages to a XMITQ, while a second later another app's message gets stuck.
3.Different channel speeds. One app may want to send NP messages over a FAST channel to get the benifits it provides, while other messages, NP or P, will send messages over a NORMAL channel.
Other than that, multiple channels between 2 QMS is just extra stuff to configure and/or break. Anyway, if one channel starts retrying because the network is down, they all will.
Let me know if I missed another valid reason to have multiple channels running at the same time.
I am all for dedicated SVRCONN channels with separate MCAUSRs though. It gives you way more control.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
