| Author |
Message
|
| Bravo |
 Posted: Thu Feb 12, 2009 5:30 pm Post subject: Bi-directional Channels |
 |
|
Centurion
Joined: 03 Oct 2005
Posts: 146
|
Hi All,
We have 2 QMGR's running on windows and 1 QMGR on AIX box. All 3 QMGR's communicate to each other
I have following questions,
What is advantage of creating 1 bi-directional channel vs multiple bi-directional channel for each project between QMGR's?
Bi-directional means
Bi-directional communication is two sets of uni-directional channels (each of which has a channel object on each side - so *four* channel objects).
What is disadvantage of using 1 bi-directional channel for all the project?.
Consider data traffic is medium. Please let me know your recommendation.
_________________
Bravo |
|
| Back to top |
|
 |
| Gaya3 |
| Posted: Thu Feb 12, 2009 7:17 pm Post subject: |
|
|
Jedi
Joined: 12 Sep 2006
Posts: 2493
Location: Boston, US
|
Suggestion:
why can't think of clustering the 3 queue managers.
instead of increasing the number of channels.
_________________
Regards
Gayathri
-----------------------------------------------
Do Something Before you Die |
|
| Back to top |
|
|
| Bravo |
| Posted: Thu Feb 12, 2009 9:40 pm Post subject: |
|
|
Centurion
Joined: 03 Oct 2005
Posts: 146
|
Thank you for your response
I recommended to the project folks but they do not want clustering
_________________
Bravo |
|
| Back to top |
|
|
| sumit |
| Posted: Fri Feb 13, 2009 12:28 am Post subject: Re: Bi-directional Channels |
|
|
Partisan
Joined: 19 Jan 2006
Posts: 398
|
| Bravo wrote: |
What is advantage of creating 1 bi-directional channel vs multiple bi-directional channel for each project between QMGR's?
|
1 set of bi-directional channel helps in easy MQ administration. It also enhance performance of queue manager as queue manager has to manage less objects.
| Bravo wrote: |
| What is disadvantage of using 1 bi-directional channel for all the project? |
The only disadvantage could be because of a requirement wherein same queue manager is in use by several application and few among them are critical. In such case, you can opt of new pair of channels for critical applications because you don't want your critical messages to wait because of some bad message posted by some non-critical application. 
_________________
Regards
Sumit |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Feb 13, 2009 1:38 am Post subject: Re: Bi-directional Channels |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Bravo wrote: |
| What is disadvantage of using 1 bi-directional channel for all the project?. |
It adds administration to no purpose. If you have medium traffic levels there's no need to segrigate urgent traffic over a faster link to ensure SLA.
It wastes resource. You have MCAs running for no good reason.
It breaks the usage model of WMQ. If by "project" you mean application or business area, neither of these should be able to see anything below queue level. How messages flow to and from their target should be irrelevant to them.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mvic |
| Posted: Fri Feb 13, 2009 1:45 am Post subject: Re: Bi-directional Channels |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
[quote="Vitor"]
| Bravo wrote: |
| It wastes resource. You have MCAs running for no good reason. |
A few Mbs per MCA.. not much of a load for newer systems. If the memory load matters that much the machine may be close to its limits. The CPU load will not be a concern because while there is nothing to send, there is practically no CPU being used by an idle MCA.
On the other hand, the concern can be addressed somewhat by using triggered channels. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Feb 13, 2009 4:07 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
In order to successfully USE more than one channel pair between qmgrs, your applications are going to have to use more than one NAME for the different qmgrs, in order to say that "project A goes over this channel and project B goes over *that* channel".
So it's not just the channels you have to create, but also qremotes that act as either remote queues or qmgr aliases. Plus additional XMITQs. |
|
| Back to top |
|
|
|
|
