| Author |
Message
|
| hsverma |
 Posted: Wed Jul 01, 2009 7:03 am Post subject: connecting to two different queue managers at the same time |
 |
|
Newbie
Joined: 29 Jun 2009
Posts: 1
|
Hi experts,
I searched through the forums but didn't find a definite answer on this and hoping you could help.
Here is the issue:
1. We currently have a client CL1 running on machine A and it connects to queue manager QM1 on machine B using MQSERVER variable.
2. We now have a new machine C which has a queue manager QM2 on it.
3. We want to connect the client CL1 to this new QM2 and also to QM1 at the SAME time. Is this possible if we use channel definitions instead of the MQSERVER variable? I know that we can open connection to QM1, then close it, then connect to QM2, then close it, then connect again to QM1 and so on, but that is a lot of MQCONN and MQCLOSE calls and I don't think it is too efficient.
Any suggestions/hints would be greatly appreciated. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Wed Jul 01, 2009 7:56 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Yes look at MQCONNX call. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Jul 01, 2009 8:21 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| but that is a lot of MQCONN and MQCLOSE calls and I don't think it is too efficient. |
If efficiency is your goal, then don't use client apps. There are increased network flows to accomodate the CC/RCs from each MQ call. Are you going to push/pull millions of messages across the client connections? If so, a qmgr-to-qmgr channel will be more efficient. My point: there are other considerations other than efficiency.
If you are using unit-of-work processing, be aware that the connection handle from the a single successful MQCONNect is used. What this means is that your app cannot use MQCMIT/MQBACK to control units-of-work that span multiple qmgrs - an MQGET from one qmgr AND an MQPUT from another qmgr in a single unit-of-work.
_________________
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 |
|
|
| RatherBeGolfing |
| Posted: Wed Jul 01, 2009 12:52 pm Post subject: |
|
|
Centurion
Joined: 12 Nov 2002
Posts: 118
Location: Syracuse, NY, USA
|
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Jul 01, 2009 3:40 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| RatherBeGolfing wrote: |
| Of course, if you're writing your app in Java, then you probably aren't using MQClient to connect to the QMgr anyway. |
90% of the hundreds of MQ Clients at my shop are Java or JMS.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Wed Jul 01, 2009 6:51 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| PeterPotkay wrote: |
| RatherBeGolfing wrote: |
| Of course, if you're writing your app in Java, then you probably aren't using MQClient to connect to the QMgr anyway. |
90% of the hundreds of MQ Clients at my shop are Java or JMS. |
MQ "client" mode for Java / JMS apps seems to be very popular, even when the app running is on the same system as the MQ Queue Manager (where "binding" mode would probably be more appropriate).
_________________
Glenn |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jul 01, 2009 9:55 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| gbaddeley wrote: |
| MQ "client" mode for Java / JMS apps seems to be very popular, even when the app running is on the same system as the MQ Queue Manager (where "binding" mode would probably be more appropriate). |
I was once told (by a source of moderate credability) that client connections are preferred in Java because of the "write once, run anywhere" ethos (or do I mean mythos?). A binding connection implies the code is on the same box as the qmgr, while a client means it can be move to this anywhere they speak of with just a configuration change.
Just someone else's $0.02. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jul 02, 2009 3:53 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Vitor wrote: |
I was once told (by a source of moderate credability) that client connections are preferred in Java because of the "write once, run anywhere" ethos (or do I mean mythos?). A binding connection implies the code is on the same box as the qmgr, while a client means it can be move to this anywhere they speak of with just a configuration change.
Just someone else's $0.02. |
Well looks to me like the people you talked to were all coding in java base....
In JMS you retrieve the connection factory from the context so no coding difference at all. The only coding changes would be running as standalone vs running in a J2EE environment and the way you specify the initial context...
No coding changes with the location of the server... It's all in the JNDI environment definitions... and the classpath...(jars) (Whether or no you need the etc client)...
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jul 02, 2009 3:56 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Why do I keep trying to add value to Java questions? Why? 
Next Week: Vitor's Guide to Bomb Disposal; Or Why Your Guide Dog Is A Bad Guide To Which Wire To Cut
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Jul 02, 2009 4:37 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| IBM have optimised client channel data flows in MQ V7 so that the statement about QM to QM channels being more efficient no longer applies. |
|
| Back to top |
|
|
| exerk |
| Posted: Thu Jul 02, 2009 5:46 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| Vitor wrote: |
...Next Week: Vitor's Guide to Bomb Disposal; Or Why Your Guide Dog Is A Bad Guide To Which Wire To Cut
|
"The blue one Harry, cut the blue one..."
_________________
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 |
|
|
| bruce2359 |
| Posted: Thu Jul 02, 2009 5:52 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| IBM have optimised client channel data flows in MQ V7 so that the statement about QM to QM channels being more efficient no longer applies. |
Some of the new client optimization options require application code changes (like read-ahead).
It is my understanding that client apps, left unmodified from prior versions, will behave the same - with multiple network flows per MQ call.
_________________
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 |
|
|
| Michael Dag |
| Posted: Thu Jul 02, 2009 6:28 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
IMHO you need to let MQ do the work, period.
if you use a client and connect to "a" point in your network,
you let MQ deliver your data "there".
Don't go about "grabbing" data from several points in the network,
that's why you got MQ in the first place...
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Jul 02, 2009 6:39 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| I agree, and I wouldn't worry about client network performance unless you are looking at hundreds of messages per second on one channel or operate on a slow network (unusual these days). |
|
| Back to top |
|
|
|
|
