| Author |
Message
|
| bruce2359 |
 Posted: Fri Jul 24, 2009 9:11 pm Post subject: |
 |
|
Poobah
Joined: 05 Jan 2008
Posts: 9471
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| I need to open 2 channels on a single QMGR from one XMITQ pointing to a remote queue. |
Why does do you believe the two channels must open the same xmit queue?
Two separate sender-reciever channel pairs between the two qmgrs will work as well. Application programs picking one QRemote or another QRemote definitions will direct messages to one of the channels.
Here are the definitions for two sender channels from qmgrA to qmgrB, with a single destinatio queue on qmgrB:
On qmgrA:
DEF CHL(A1.B1) CHLTYPE(SENDER) TRPTYPE(TCP) CONNAME(qmgrB(1414)) XMITQ(B1)
DEF CHL(A2.B2) CHLTYPE(SENDER) TRPTYPE(TCP) CONNAME(qmgrB(1415)) XMITQ(B2)
DEF QR(DESTQ.BY.B1) XMITQ(B1) RNAME(DESTINATION.QUEUE)
DEF QR(DESTQ.BY.B2) XMITQ(B2) RNAME(DESTINATION.QUEUE)
DEF QL(B1) USAGE(XMITQ)
DEF QL(B2) USAGE(XMITQ)
On qmgrB
DEF CHL(A1.B1) CHLTYPE(RCVR) TRPTYPE(TCP)
DEF CHL(A2.B2) CHLTYPE(RCVR) TRPTYPE(TCP)
DEF LISTENER(TCP.1414) PORT(1414)
DEF LISTENER(TCP.1415) PORT(1415)
DEF QL(DESTINATION.QUEUE)
When an application on qmgrA MQOPENs DESTQ.BY.B1 the message is transmitted by A1.B1. When an application MQOPENs DESTQ.BY.B2, the message is transmitted by A2.B2. Both messages will end up in DESTINATION.QUEUE.
(I'm sure I missed or mistyped something... it's late.)
_________________
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 |
|
 |
| pheiro |
| Posted: Fri Jul 24, 2009 10:45 pm Post subject: |
|
|
Newbie
Joined: 22 Jul 2009
Posts: 5
|
Appreciate your writing in so late so elaborately
But i know all this!
| Quote: |
| I need to open 2 channels on a single QMGR from one XMITQ pointing to a remote queue. |
Actually there is a need to put certain kind of messages to 1 channel and of another type to another. Just like it was mentioned
| Quote: |
I have used separate channel pairs to separate real-time traffic from batch traffic. |
Please let me know if the concept itself is possible of
| Quote: |
opening 2 channels on a single QMGR from one XMITQ pointing to a remote queue. |
 |
|
| Back to top |
|
|
| exerk |
| Posted: Sat Jul 25, 2009 1:52 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| pheiro wrote: |
| ...Please let me know if the concept itself is possible of opening 2 channels on a single QMGR from one XMITQ pointing to a remote queue. |
As has been said, with 'vanilla' point-to-point - NO! With clusters - YES!
If you have a need to separate traffic, separate it properly.
_________________
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 |
|
|
| fjb_saper |
| Posted: Sat Jul 25, 2009 2:55 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
To add to Bruce's post... There is no need to separate the port #.
We have the same setup from a mainframe to a distributed qmgr and there is only one listener running and both channels use the same port.
Bandwidth is not the problem but we managed to have better throughput with both channels....
I guess the problem is really at that point how fast the application can remove the messages from the target queues to avoid them filling up... and backing up on the sender's xmit queue. Splitting the channels helps with the distribution of the messages and the scaling of the target apps.
Mainframe batches can tax the channels that way...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Jul 25, 2009 6:21 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9471
Location: US: west coast, almost. Otherwise, enroute.
|
More specifically: Mainframe batches can tax the midrange (Windows/UNIX) channels and midrange processors that way...
_________________
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 |
|
|
| SAFraser |
| Posted: Sat Jul 25, 2009 6:41 am Post subject: |
|
|
Shaman
Joined: 22 Oct 2003
Posts: 742
Location: Austin, Texas, USA
|
I still don't understand what you are trying to do. What is the business requirement you are trying to satisfy?
| Quote: |
| Actually there is a need to put certain kind of messages to 1 channel and of another type to another. Just like it was mentioned |
Why must it be a single xmitq? I don't get it.
When I want to separate, for example, real-time messages from batch messages, the real-time messages go to a remote queue that uses an xmitq for a channel dedicated to real-time traffic; and, the batch messages go to a separate remote queue that uses an xmitq for a channel dedicated to batch.
There must be something in the way the original message is being addressed at PUT that is driving this requirement? Or is it the receiving end of things? If you would explain your requirement fully, I think we could give better opinions!
 |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Jul 25, 2009 7:04 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9471
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
I need to have 2 channels on a QM connecting to same destination QM at the same time.
Can any one tell me how can i do this |
?
You have been told how to do this, namely: two sender-receiver pairs between the qmgrs.
MQ does not support xmit queue sharing (except clusters). Read the WMQ Intercommunications manual.
What requirement dictates that your channels MUST share a xmit queue?
Business requirements dictate results (like getting more messages from qmgrA to qmgrB), NOT exactly how this is to be accomplished.
I understand that you want to share an xmitq; but since you can't, what purpose do you believe xmit queue sharing offers you that additional channel pairs do not?
_________________
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 |
|
|
| fjb_saper |
| Posted: Sun Jul 26, 2009 2:02 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
If you are looking for failover routing without having to wait for messages already on the xmitq, this is possible by defining the same xmitq for both channels.
- Understand that both channels will NEVER run at the same time.
- Understand as well that in order for channel triggering to work you MUST populate the xmitq with the channel name.
- Understand as well that the throughput will be limited to that of the specific route/interface/... used.
This is not a way to boost throughput, but a way to make the destination qmgr available when the normal channel is down for whatever network related reason. This could involve the use of multihopping (channel from A to C is down tcpip cannot resolve hostname etc... but channels from A to B and B to C work fine... So defining a second channel from A to B with the xmitq from A to C allows you to forward the waiting msgs to C via the B qmgr...)
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| pheiro |
| Posted: Sun Jul 26, 2009 5:08 am Post subject: |
|
|
Newbie
Joined: 22 Jul 2009
Posts: 5
|
Guys than you for the valuable inputs.
I have realized that the XMITQ has exclusive input so i can' thave 2 channels on at the same time.
Firstly
I needed to distinguish on 2 different types of messages and for that s rightly put i'll have to put that on 2 different XMITQ
Secondly
I needed a kind of back up when one of the channels id down for any reason.
I thought triggering the channel would help.
But i think Clustering would be the right solution for these requirements
because i can't have the 2nd channels on immediately based on queue depth as soon as the first channel goes down or any such trivial logics.
This sounds kind of risky and temporary solution
So going for clustering appears to be the only go!! |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Sun Jul 26, 2009 3:42 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| pheiro wrote: |
...Secondly
I needed a kind of back up when one of the channels id down for any reason.
I thought triggering the channel would help... |
"back up" channels for sdr/receiver betwen 2 qmgrs are not very useful. If one pair of channel is having problems that can't be resolved (eg. a network failure) it is highly likely that the second pair will experience the same problem, unless you can arrange for them to take a different network route.
_________________
Glenn |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jul 27, 2009 5:02 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| pheiro wrote: |
Firstly
I needed to distinguish on 2 different types of messages and for that s rightly put i'll have to put that on 2 different XMITQ |
It remains pointless to use 2 different XMITQs unless you have 2 different network routes. If you need to distinguish message types, deliver them to 2 different target queues.
Note that you can't control XMITQs inside a cluster.
| pheiro wrote: |
Secondly
I needed a kind of back up when one of the channels id down for any reason.
I thought triggering the channel would help. |
Again, if you've only one network route then both channels will fail.
| pheiro wrote: |
| So going for clustering appears to be the only go!! |
It might help with your message delivery and distribution, but isn't going to solve your network questions.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
