| Author |
Message
|
| bkiran2020 |
 Posted: Sat Jan 12, 2013 2:31 am Post subject: two Remote queue definition using same XMITQ and channel. |
 |
|
Master
Joined: 20 Jan 2011
Posts: 243
Location: US
|
sender side:
two Remote queue definition using same XMITQ and channel.
What is the use of using the same same XMITQ and channel. in distribution. |
|
| Back to top |
|
 |
| sumit |
| Posted: Sat Jan 12, 2013 5:10 am Post subject: |
|
|
Partisan
Joined: 19 Jan 2006
Posts: 398
|
|
| Back to top |
|
|
| exerk |
| Posted: Sat Jan 12, 2013 5:42 am Post subject: Re: two Remote queue definition using same XMITQ and channel |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| bkiran2020 wrote: |
sender side:
two Remote queue definition using same XMITQ and channel.
What is the use of using the same same XMITQ and channel. in distribution. |
Have you tried it? Experimented? Anything other than post here first and read manuals second?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| bkiran2020 |
| Posted: Sun Jan 13, 2013 12:09 am Post subject: Re: two Remote queue definition using same XMITQ and channel |
|
|
Master
Joined: 20 Jan 2011
Posts: 243
Location: US
|
| exerk wrote: |
| bkiran2020 wrote: |
sender side:
two Remote queue definition using same XMITQ and channel.
What is the use of using the same same XMITQ and channel. in distribution. |
Have you tried it? Experimented? Anything other than post here first and read manuals second? |
yes i have tired it...if i tried how can i know about the exact use.
I know that it will reduce the resource that are use But iam not sure soo raised this question...
 |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Jan 13, 2013 5:50 am Post subject: Re: two Remote queue definition using same XMITQ and channel |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| bkiran2020 wrote: |
What is the use of using the same same XMITQ and channel. in distribution. |
The general purpose is to share a single channel path between two qmgrs. Different applications can MQOPEN different QRemote definitions that make use of the same xmitq and channel.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Vitor |
| Posted: Sun Jan 13, 2013 10:53 am Post subject: Re: two Remote queue definition using same XMITQ and channel |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bkiran2020 wrote: |
yes i have tired it...if i tried how can i know about the exact use.
I know that it will reduce the resource that are use But iam not sure soo raised this question...
|
Here's a better question. If you have 2 remote queue definitions that point to the same remote queue manager, why wouldn't you use the same xmitq and channel for them?
The answer to that question gives you a list of scenarios. For all the others you'd use the same.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| umatharani |
| Posted: Fri Jan 18, 2013 12:37 am Post subject: |
|
|
Apprentice
Joined: 23 Oct 2008
Posts: 39
|
Multiple channels might be required if one channel is not able to handle the message load on the XMITQ and/or to process some critical messages separately with no interruption from the messages put to non critical queues.
RQs for critical messages -> XMITQ1 -> CHL1
RQs for other messages -> XMITQ2 -> CHL2 |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Jan 18, 2013 4:58 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
A second channel between qmgrs might be SSL-enabled to carry messages that need to flow encrypted.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jan 18, 2013 6:32 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| umatharani wrote: |
Multiple channels might be required if one channel is not able to handle the message load on the XMITQ and/or to process some critical messages separately with no interruption from the messages put to non critical queues.
RQs for critical messages -> XMITQ1 -> CHL1
RQs for other messages -> XMITQ2 -> CHL2 |
Only if the 2 channels used 2 different network paths. Otherwise you're pushing both classes over the same overloaded network route. But yes, especially if the critical messages have a short SLA & you want to explicitly use a fast network route which is in short supply or expensive for those & let other messages just stroll across the copper.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| SAFraser |
| Posted: Fri Jan 18, 2013 1:26 pm Post subject: |
|
|
Shaman
Joined: 22 Oct 2003
Posts: 742
Location: Austin, Texas, USA
|
I agree with the other posters. Using the same channel would be a "default" design choice for me. Situations where I might want separate channels include:
1. Trading partner has two or more applications, one of which misbehaves and causes a queue full (and then channel pauses). This misbehaving application might get its own channel to prevent harm to other, more civilized consumers. (Before you seniors start to lecture me, please note that I cannot always impact application design at a trading partners' site.)
2. Transactions are a mix of large volume batch and real-time (synchronous or request-reply) messages. Might use separate channels so real-time messages don't get stuck in a xmitq behind a bunch of batch messages.
3. To satisfy some (silly) business requirement, we need to be able to stop message traffic to one consumer but leave other message traffic flowing.
This is the great thing about MQ -- one can tweak the MQ design to satisfy many business requirements and operational situations! |
|
| Back to top |
|
|
|
|
