Author |
Message
|
chenxiaohua |
Posted: Tue Jun 20, 2006 7:00 pm Post subject: How to connect more than one queue manager? |
|
|
Newbie
Joined: 15 Jun 2006 Posts: 1
|
Hello!
I want to connect two queue manager in one application, i am working on c++.
I get 2002 error code when i connect second qmgr, but i can get two on java application. why? if can't get more than one connection in one thread, what shall i do?
who have some demo witch resolve this problem. |
|
Back to top |
|
 |
RogerLacroix |
Posted: Tue Jun 20, 2006 10:22 pm Post subject: |
|
|
 Jedi Knight
Joined: 15 May 2001 Posts: 3264 Location: London, ON Canada
|
Hi,
Make each queue manager connection request in separate threads.
Regards,
Roger Lacroix
Capitalware Inc. _________________ Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
Back to top |
|
 |
wschutz |
Posted: Wed Jun 21, 2006 1:37 am Post subject: |
|
|
 Jedi Knight
Joined: 02 Jun 2005 Posts: 3316 Location: IBM (retired)
|
Can you tell us why you need to connect to two qmgrs in your application? This isn't a "typical" programming pattern.... _________________ -wayne |
|
Back to top |
|
 |
tleichen |
Posted: Wed Jun 21, 2006 10:56 am Post subject: |
|
|
Yatiri
Joined: 11 Apr 2005 Posts: 663 Location: Center of the USA
|
If you just make a channel between the two queue managers along with approriate xmit queues, etc., you should be able to architect a solution that will not require your application to connect to two queue managers directly.  _________________ IBM Certified MQSeries Specialist
IBM Certified MQSeries Developer |
|
Back to top |
|
 |
jefflowrey |
Posted: Wed Jun 21, 2006 2:26 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
wschutz wrote: |
Can you tell us why you need to connect to two qmgrs in your application? This isn't a "typical" programming pattern.... |
Unless one is writing a monitoring program.
Or a web-administration program. _________________ I am *not* the model of the modern major general.
Last edited by jefflowrey on Fri Jun 23, 2006 2:12 am; edited 1 time in total |
|
Back to top |
|
 |
boydl |
Posted: Fri Jun 23, 2006 2:06 am Post subject: |
|
|
Novice
Joined: 05 Feb 2003 Posts: 16
|
Another reason for doing such thing is for the "Replying" application having a client connecting to a cluster of queue managers.
The requesting application (Client connection) can put messages to any of the clustered queue manager. Hence, the replying apps need to ensure that it can get messages from all of the queue manager in the cluster. |
|
Back to top |
|
 |
jefflowrey |
Posted: Fri Jun 23, 2006 2:17 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
boydl wrote: |
The requesting application (Client connection) can put messages to any of the clustered queue manager. Hence, the replying apps need to ensure that it can get messages from all of the queue manager in the cluster. |
No. You have that very confused.
In a request/reply scenario the requester (client) sends a message to a known queue on a particular queue manager. The server app reads from this queue, and is only connected to that one queue manager. The request message indicates what queue the client wants to receive the reply on, and also what queue manager that queue lives on. The server app does NOT then open a new client connection to that queue manager. The server app merely opens the reply-to-queue and reply-to-queue manager, and puts the reply. MQ networking handles moving the message to the right place.
In a cluster scenario, there can be multiple copies of a particular queue - for example the server app queue can exist more than once. THEN messages will be "sprayed" out to all of those queues. BUT it is NOT expected that a single instance of the server app will be GETTING from all of those queues. It is expected that there are multiple copies of that server app, each getting from a single queue. Otherwise you have removed all the scalability you have just gotten by adding the cluster and multiple queue instances! _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
|