Author |
Message
|
insanemorgoth |
Posted: Tue Mar 21, 2006 9:27 pm Post subject: Connecting to more then one queue manager |
|
|
Newbie
Joined: 13 Dec 2005 Posts: 7
|
Hello,
I have an application need where I need to connect to one queue manager, put a message there, and then connect to another queue manager, and get a message from there, both in the same thread without disconnecting from the first queue manager.
Is this possible. Websphere MQ client manual says that it is possible by specifying * as the queue manager name in MQCONN command, but example seem to say that it will just pick up one of the queue manager based on client channel available. IT does not explain if the application will be able to connect to two queue managers at the same time. This is on HP-UX 11.11
Thanks. |
|
Back to top |
|
 |
elvis_gn |
Posted: Tue Mar 21, 2006 9:46 pm Post subject: |
|
|
 Padawan
Joined: 08 Oct 2004 Posts: 1905 Location: Dubai
|
Hi insanemorgoth,
Which manual did you get the info from...can u post the para from it.
Also, it is possible to connect to two QM's at one time as long as you are using different connection objects.
Regards. |
|
Back to top |
|
 |
Nigelg |
Posted: Wed Mar 22, 2006 12:42 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004 Posts: 1046
|
Quote: |
Also, it is possible to connect to two QM's at one time as long as you are using different connection objects.
|
Not on the same thread on HPUX it isn't. _________________ MQSeries.net helps those who help themselves.. |
|
Back to top |
|
 |
wschutz |
Posted: Wed Mar 22, 2006 3:11 am Post subject: |
|
|
 Jedi Knight
Joined: 02 Jun 2005 Posts: 3316 Location: IBM (retired)
|
The MQ client has always allowed you to connect to more than one queue manager at a time in a single thread, but it's probably not wise to take advantage of that. _________________ -wayne |
|
Back to top |
|
 |
zpat |
Posted: Wed Mar 22, 2006 3:23 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
It's generally a better design to route the messages between the queue managers and have the MQ client connect to only one QM. |
|
Back to top |
|
 |
jsware |
Posted: Wed Mar 22, 2006 5:10 am Post subject: |
|
|
 Chevalier
Joined: 17 May 2001 Posts: 455
|
Some may say that client connections have security issues but lets not discuss it here - there's plenty of that already available via the search option.
If you want to connect to multiple queue managers in bindings mode, it can be done with a little (legal) wizardry.
I've created a wrapper library before so that each session (aka HCONN) has a background worker thread. You can then create two sessions (each having its own background worker thread) and do puts/gets to multiple qmgrs in bindings mode. Each MQ call sets up a data area and signals the worker thread to do its stuff. Once done, the worker thread signals the main thread its finished.
If you're looking to coordinate with XA, this won't work unless your worker thread can be extended to do all the DB work too. _________________ Regards
John
The pain of low quaility far outlasts the joy of low price. |
|
Back to top |
|
 |
insanemorgoth |
Posted: Wed Mar 22, 2006 9:57 am Post subject: |
|
|
Newbie
Joined: 13 Dec 2005 Posts: 7
|
THank you all for your responses
but can some one help me understand -->
What is wrong with having two different mqconn/mqconnx command in same program with different queue manager name and then use each connection handle depending on which queue needs to be read/written to. Is this a valid thing architecturally or am I going to get an error on 2nd Mqconn. |
|
Back to top |
|
 |
jefflowrey |
Posted: Wed Mar 22, 2006 10:45 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
From a design point of view, for putting messages an MQ application should have no idea which queue manager some particular queue lives on.
From a design point of view, for getting messages there is no reason for an application to need queues on more than one queue manager.
From an MQ network point of view, it is better to have applications be written in such a way that the MQ network can change configuration and applications can change locations and queue managers they connect to without the application being changed.
So, from a design point of view an application should never need to know about more than one queue manager at a time.
The only cases where this is not true is monitoring applications - and even then it is better to use an agent/server approach such that each agent only connects to one queue manager. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
|