Author |
Message
|
Vin |
Posted: Wed Aug 21, 2002 11:58 am Post subject: Multiple Channel instances |
|
|
Master
Joined: 25 Mar 2002 Posts: 212 Location: India
|
Can anyone tell me how to run multiple instances of the channel? The platform in Sun Solaris and the MQ version is 5.2. Thanks so much. |
|
Back to top |
|
 |
bduncan |
Posted: Wed Aug 21, 2002 12:29 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001 Posts: 1554 Location: Silicon Valley
|
You will need to provide a little more detail about what you want to do. There are several ways to interpret your question. I'm assuming you want to allow more than one pair of channels between queue manager A and queue manager B. This is relatively straightforward. Simply define another sender and receiver channel pair on A and B, naming them something different from the original channels. Then create additional transmission queues. _________________ Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
Back to top |
|
 |
Vin |
Posted: Wed Aug 21, 2002 6:29 pm Post subject: |
|
|
Master
Joined: 25 Mar 2002 Posts: 212 Location: India
|
Brandon,
What I meant was to have a Single transmission queue and multiple instances of the same channel using this transmission queue. That way the messages from this transmission queue would be shipped faster right? Can you let me know if this possible? I can only have one transmission queue which has the same name as the remote queue manager. Thanks so much. |
|
Back to top |
|
 |
RogerLacroix |
Posted: Wed Aug 21, 2002 7:58 pm Post subject: |
|
|
 Jedi Knight
Joined: 15 May 2001 Posts: 3264 Location: London, ON Canada
|
No, that is not possible.
1 transmission queue per sender channel (or server channel). It is a 1 to 1 relationship.
You can call your transit queue whatever you want. But if it is not the same name as the remote queue manager, then you will need to create a queue manager alias definition.
later
Roger... _________________ Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
Back to top |
|
 |
nimconsult |
Posted: Wed Aug 21, 2002 10:31 pm Post subject: |
|
|
 Master
Joined: 22 May 2002 Posts: 268 Location: NIMCONSULT - Belgium
|
Multiple instances of the same channel is not possible.
I am not quite sure that multiple instances of the same channel would give you more performance: they would all use the same network connection, so you will be limited by the network bandwidth anyhow.
There is an overhead that you might want to suppress: the confirmations of the receiver channel between each message batches. Websphere MQ provides a way of eliminating this overhead: assign "PipelineLength=2" in your qm.ini file. _________________ Nicolas Maréchal
Senior Architect - Partner
NIMCONSULT Software Architecture Services (Belgium)
http://www.nimconsult.be |
|
Back to top |
|
 |
jhalstead |
Posted: Thu Aug 22, 2002 1:08 am Post subject: |
|
|
 Master
Joined: 16 Aug 2001 Posts: 258 Location: London
|
"You can call your transit queue whatever you want. But if it is not the same name as the remote queue manager, then you will need to create a queue manager alias definition. "
Odd, I've been calling my transmission queues all sorts of things without any problems... Is this a quirk I don't know about? Can you illustrate with an example Roger?
Thanks
Jamie |
|
Back to top |
|
 |
PeterPotkay |
Posted: Thu Aug 22, 2002 8:05 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
QM1 has connections to QM2, QM3 and QM4.
An app connected to QM2, QM3 or QM4 puts a request to RequestQ, which is a remote queue def that points to RequestQ on QM1. The app specifies its reply2queue as ReplyQ and its reply2QM as QM2, QM3 or QM4.
The replying app picks up the request on QM1, and then goes to put its reply based on the reply2queue info. On the MQOPEN, it specifies ReplyQ for the queue and QM2, QM3 or QM4 for the queue manager. MQ name resolution now kicks in. The first thing it checks for is a queue that has the same name as the queue manager name on the open.
If you have an XMIT queue named after QM2, QM3 and QM4, then this process will allow replies to flow back to the appropriate QM without having to manually define remote queue defs for all the reply queues.
If you call the XMIT going to QM2 something like AppleBanana, then name resolution would not work, and you would have to define remte defs for all the reply queues, and in each def you would specify AppleBanana as the XMIT queue. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
RogerLacroix |
Posted: Thu Aug 22, 2002 8:06 am Post subject: |
|
|
 Jedi Knight
Joined: 15 May 2001 Posts: 3264 Location: London, ON Canada
|
Hi,
I should have qualified it to be: "When an application puts to a remote queue without having a remote queue definition on the local queue manager".
You probably have lots of remote queue definitions to get the message into the correct transmit queue.
A good example would be if the appliation opens a remote queue by specifying BOTH the queue manager (remote) name and queue (remote) name. If you do not have EITHER the transmit queue name the same as the remote queue manager name OR a queue manager alias defined to point to the remote queue manager then it will fail with a 2085 (Unknown object name).
later
Roger... _________________ Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
Back to top |
|
 |
PeterPotkay |
Posted: Thu Aug 22, 2002 8:08 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
Roger, The default XMIT queue attribute of the Queue Manager will be invoked before an app would get the 2085 (assuming it was set at the QM level). _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
RogerLacroix |
Posted: Thu Aug 22, 2002 8:16 am Post subject: |
|
|
 Jedi Knight
Joined: 15 May 2001 Posts: 3264 Location: London, ON Canada
|
Since I had to debug a large MQ environment that used default XMITQ, it had messages going forever in a loop (e.g. QMA -> QMB -> QMC -> QMA). I disallow the use of default XMITQ. The application had a typo in the queue name and the messages just went around and around and around and around and ...
I pulled out too many hairs trying to figure out what the hell was going on. So, I don't allow it. (I gotta keep what little hair I have left. )
later
Roger... _________________ Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
Back to top |
|
 |
PeterPotkay |
Posted: Thu Aug 22, 2002 9:36 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
I guess there are times to use it and times not to.
We have this atribute set on all our spoke queue managers with the default value being the Hub QM. The Hub QM has XMIT queues named after all the spoke QMs.
Works good and saves us a ton of queue definition work. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
Vin |
Posted: Thu Aug 22, 2002 5:07 pm Post subject: |
|
|
Master
Joined: 25 Mar 2002 Posts: 212 Location: India
|
We did the same thing as what peter had in the conversation. We defined transmission queues on the sending side and had queue manager alias definitions which would have the same name as the transmission queue. This way there are more transmission queues to ship the messages back. We are seeing a performance improvement already.
There is an overhead that you might want to suppress: the confirmations of the receiver channel between each message batches. Websphere MQ provides a way of eliminating this overhead: assign "PipelineLength=2" in your qm.ini file.
Do we have to restart the queue manager after this?
Thanks to everyone for all the suggestions. |
|
Back to top |
|
 |
nimconsult |
Posted: Fri Aug 30, 2002 12:07 am Post subject: |
|
|
 Master
Joined: 22 May 2002 Posts: 268 Location: NIMCONSULT - Belgium
|
Quote: |
There is an overhead that you might want to suppress: the confirmations of the receiver channel between each message batches. Websphere MQ provides a way of eliminating this overhead: assign "PipelineLength=2" in your qm.ini file.
Do we have to restart the queue manager after this?
|
Not 100% sure, but I think you should restart the queue manager so that the updated "qm.ini" is read again. _________________ Nicolas Maréchal
Senior Architect - Partner
NIMCONSULT Software Architecture Services (Belgium)
http://www.nimconsult.be |
|
Back to top |
|
 |
chrisng |
Posted: Thu Sep 12, 2002 5:24 pm Post subject: Pipelinelength no available for MQ V5.2 OS/390 |
|
|
Newbie
Joined: 26 May 2002 Posts: 7
|
In my case, unfortunately, Pipelinelength is only supported on these platforms but not OS/390.
MQSeries for AIX¦, V5.2
MQSeries for AS/400¦, V5.2
MQSeries for HP-UX, V5.2
MQSeries for Linux, V5.2
MQSeries for Sun Solaris, V5.2
MQSeries for Windows NT¦ and Windows¦ 2000, V5.2 |
|
Back to top |
|
 |
|