| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| cluster qm connects to distributed qm |
« View previous topic :: View next topic » |
| Author |
Message
|
| skytorch |
 Posted: Tue Jul 09, 2002 12:24 pm Post subject: cluster qm connects to distributed qm |
 |
|
Apprentice
Joined: 10 Jun 2002
Posts: 47
Location: New York City
|
Hi,
I have two QMs (QM1, QM2) in a cluster. These QMs are using distributed queueing to connect to the same queue of a QM - QM3 (QM3 is residing at client side, so can not be added to the cluster), i.e. both QM1 and QM2 are using separate remote queue and tranmission queue to connect to the same queue in QM3.
How many physical connections are going to the client side? What issues this approach may have, especially the connections are going across the client side firewalls ?
I noticed that remote queues and transmission queues can be shared in the cluster. In what situation, should I share or not share these MQ objects ?
Thanks in advance.
Sky |
|
| Back to top |
|
 |
| bduncan |
| Posted: Tue Jul 09, 2002 12:33 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Sky,
The number of physical connections should be 2, the way you have it setup, one for each channel. I suppose the number of connections shouldn't be the main issue with firewalls, rather, if both queue managers are using the same port(s) for communications with the outside, then as long as the firewall lets this port out, any number of queue managers should be able to see the outside.
Well, if you share, you are now introducing a single point of failure. If the one queue manager in the cluster which has the channel going to the outside goes down, none of the other queue managers in the cluster will be able to communicate with the outside as well. However, all the messages would pile up on the various transmission queues, and would eventually flow when the queue manager came back up. But sharing has the distinct advantage of decreasing your administration overhead because there is only one remote queue, transmission queue, and channel to keep an eye on, rather than multiple ones spread across multiple queue managers.
In my experience, when I need one or more queue managers in a cluster to communicate with a queue manager outside of that cluster, I only create the necessary objects/channels on one queue manager, and let the other queue managers in the cluster use him as a middle man to communicate with the outside.
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| 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
|
|
|
|
