| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Clustering vs Remote Q Definition |
« View previous topic :: View next topic » |
| Author |
Message
|
| rajarshi |
 Posted: Thu Apr 06, 2006 2:19 am Post subject: Clustering vs Remote Q Definition |
 |
|
Newbie
Joined: 06 Apr 2006
Posts: 3
|
Hello all,
i am new with WebSpere MQ. I want to know if we can cluster different Q Managers residing geographically in different boxes, then why do we use Remote Queue Definiton? We can cluster the Queue Manager and treat the Queue as a local Queue !!!
Thanks,
-- Raj. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Apr 06, 2006 2:28 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Try reading some of the documentation. 
The point of MQ is to connect queue managers residing geographically in different boxes. It's marketed as a better way to communicate between geographically separate boxes than native TCP/IP.
To this end remote queue definitions and cluster are two ways to achieve this. There is a multiude of reasons why you'd pick one over the other and it depends a lot on your requirements, design ethos of your site, etc, etc, etc.
I offer this as a scenario. You have 3 queue managers in a cluster, geographically separate and linked as you describe. You have a link to a 3rd party supplier who wants to communicate with you via MQS but will not add his queue manager to your cluster for political reasons. You'd therefore set up point to point with him & a remote queue et al.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Apr 06, 2006 4:34 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You can never treat a QCLUSTER or QREMOTE as a QLOCAL.
From an application point of view, there is no difference between a QCLUSTER and a QREMOTE. But there is a single, HUGE, difference between both of those and a QLOCAL. You can only GET from QLOCALs.
Whether or not to Cluster queue managers or connect them using standard channels is an Infrastructure decision, and not a Developer decision.
Clustering is not well suited for a lot of Infrastructure layouts, or network topologies. Conversely, it is well suited for other Infrastructure layouts and network topologies.
It is usually better to use standard channel connections unless there are specific reasons to use Clustering.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| rdubey |
| Posted: Sat Aug 26, 2006 10:31 am Post subject: |
|
|
Novice
Joined: 11 Jul 2006
Posts: 17
Location: USA
|
when should we not use clusters ?
I have 2 qmanagers which are part of 2 clusters . now I am thinking
that it will be difficult to determine which channles messages might be
flowing ? we wanted to implement a message exit but I think its possible for some messages to travel on different cluster channel and the exit will never be invoked ?
I am thinking of using the standard sender receiver channels to avoid this problem . since qmanager is being used by whole lot of different apps
which use one of the cluster I can not avoid having qmanager being part of one cluster . I can avoid to have this qm part of second cluster and
use standard channels to communicate to the other qmanager .
I also want to know when should we not use clusters ? |
|
| Back to top |
|
|
| jeevan |
| Posted: Sun Aug 27, 2006 8:44 pm Post subject: |
|
|
Grand Master
Joined: 12 Nov 2005
Posts: 1432
|
| The basic principle of ushing CLUSTER is to achieve load balancing among many queue manager. If load balancing is not your goal and you are using other stuff, like exit, and does not seem any near future requirement of lb, u dun need to have cluster |
|
| 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
|
|
|
|
