Author |
Message
|
gunter |
Posted: Thu Sep 22, 2005 7:03 am Post subject: Two Connections in one Application |
|
|
Partisan
Joined: 21 Jan 2004 Posts: 307 Location: Germany, Frankfurt
|
Hello,
Im trying to fix a problem with two connection from one application to different queuemanager. The application is developed in a delphi-like language. Two libraries using mq are loaded dynamically. One uses a client-connection, the other bindings. It worked without any problem until the update to 5.3.
With 5.3 on AIX 5.3 we get errors because of the queue isn't known at the queuemanager.
I know, it's not the right way to use mq with more than one connection in a thread, even it's hidden in a library. It's not up to me to change the behavior of the library, I would prefer to use only a connection to one queuemanager.
I think the problem ca only be solved if the application uses one queumanager.
Has anybody experience how to cope with such a problem ?
Is it possible to use both client and server lib together in one application ?
How ist ist with two connections to the same queuemanager ? It works, but is ther a problem hidden?
Thanks in advance
Gunter _________________ Gunter Jeschawitz
IBM Certified System Administrator - Websphere MQ, 5.3 |
|
Back to top |
|
 |
jefflowrey |
Posted: Thu Sep 22, 2005 7:05 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
I think it's, in fact, not supported or possible to establish both a client connection and a bindings connection in the same thread.
You can certainly establish two client connections in the same thread. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
hopsala |
Posted: Thu Sep 22, 2005 8:08 am Post subject: |
|
|
 Guardian
Joined: 24 Sep 2004 Posts: 960
|
I really don't see why you should use a client connection *and* server bindings, since you can use a client connection to connect locally; if you have a prog which (for some god forsaken reason) wishes to connect to more than one qm on many machines, simply link it with the client lib.
In any event, usually one links with either client or server lib, I really don't know how it works with loading two, and am slightly surprised that it worked up to version 5.3.
gunter wrote: |
With 5.3 on AIX 5.3 we get errors because of the queue isn't known at the queuemanager. |
Means that you are probably connecting to the wrong qm, which may be the effect of your strange lib duo. Best way to find out to which qm you have connected, is MQOPEN the qmanager and MQINQ for its name.
gunter wrote: |
How ist ist with two connections to the same queuemanager ? It works, but is ther a problem hidden? |
(working assumption: I assume by "ist ist" you meant "is it")
The "hidden" problem concerns syncpoints, when using two connections, you only commit one of your connection handles at a time, and if you didn't code your appl accordingly, you might lose data.
Mind if I ask what this program of yours does exactly? |
|
Back to top |
|
 |
gunter |
Posted: Thu Sep 22, 2005 8:36 am Post subject: |
|
|
Partisan
Joined: 21 Jan 2004 Posts: 307 Location: Germany, Frankfurt
|
Thank you for yor fast response.
I faced with two problems, one ist to solve the problem. I assume, I can't do it without the developers of the libraries. This will take time and I need good arguments. The other ist to get the system running, today better than tomorrow.
The shared libraries are written in C and the access to MQ is far behind the interface, so I have not access to the connection handle. The libs don't use syncpoints.
To make a quick fix I tried to load and unload the librariers for each batch of messages, but it's still the same behavior.
My solution for the problem is to use bindings in both libraries to the local queuemanager and a channel to the remote one. The only problem is, that each library has its own connection an can control it only by disconnect after each access. _________________ Gunter Jeschawitz
IBM Certified System Administrator - Websphere MQ, 5.3 |
|
Back to top |
|
 |
jefflowrey |
Posted: Thu Sep 22, 2005 8:39 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
I was assuming that the libraries would let you specify the queue manager connection information (qmgr name or host/channel/port). If so, you just need to specify host/channel/port for both connections.
If not, yeah, you have to go back to the library developers. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
gunter |
Posted: Fri Sep 23, 2005 2:32 am Post subject: |
|
|
Partisan
Joined: 21 Jan 2004 Posts: 307 Location: Germany, Frankfurt
|
Hi,
many thanks for your help.
It works now. I linked both libraries with the mq client lib and configured a channel table. I'm not so happy to use a client connection to a local queuemanager.
At least it's good enough as a workaround, maybe it's also the final solution. It will be to hard work to get the developer change their code.
Gunter _________________ Gunter Jeschawitz
IBM Certified System Administrator - Websphere MQ, 5.3 |
|
Back to top |
|
 |
fjb_saper |
Posted: Fri Sep 23, 2005 3:13 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Gunter,
I 've had some trouble with the same type of setup.
As long as you don't do any gets from the remote qmgr, you could try what I had to do in order to access 2 different local qmgrs (bindings) from the same thread:....
Make sure you always access the local qmgr first.
On the local qmgr create a client connection channel to the remote qmgr.
See if you can access the remote qmgr... Like I said both were local qmgrs for me and I still had to set up the client channel in order to be able to connect to the second one from the same thread while having the first one open...
Enjoy  |
|
Back to top |
|
 |
hopsala |
Posted: Fri Sep 23, 2005 5:34 am Post subject: |
|
|
 Guardian
Joined: 24 Sep 2004 Posts: 960
|
gunter wrote: |
It works now. I linked both libraries with the mq client lib and configured a channel table. I'm not so happy to use a client connection to a local queuemanager.
At least it's good enough as a workaround, maybe it's also the final solution. It will be to hard work to get the developer change their code. |
It is important to emphesize that this is *not* a workaround, it is a valid, widely-used way to use WMQ clients when having an application which connects to many qms; this is how many monitoring products work. All the potential problems one has with clients are not relevant once you connect locally, since in fact, no network communication is involved - the packet is sent to the local tcp service, and is immediately sent back to the computer without being broadcast to the net, so no performance degredation or network dependancy.
This is also commonly used in backup scnerios - if you wish your application to automatically switch to a backup qm if the main one is offline, the way to do it is to link it with the client library and use a channel table.
I have applied both scenarios in at least different 5 sites, and it works like a charm; there is a very slight performance degredation, due to the nature of client channels, but very slight indeed.
If I am not persuasive enough, or there's something I need to learn here, tell me - why is it that you are "not so happy to use a client connection to a local queuemanager"? |
|
Back to top |
|
 |
fjb_saper |
Posted: Fri Sep 23, 2005 6:27 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Perhaps because of 2 phase commit ?
 |
|
Back to top |
|
 |
hopsala |
Posted: Fri Sep 23, 2005 7:09 pm Post subject: |
|
|
 Guardian
Joined: 24 Sep 2004 Posts: 960
|
|
Back to top |
|
 |
gunter |
Posted: Sat Sep 24, 2005 11:09 am Post subject: |
|
|
Partisan
Joined: 21 Jan 2004 Posts: 307 Location: Germany, Frankfurt
|
fjb_saper,
maybe I didn't really understand your response.
Is it possible to send a message over a local to an remote queuemanager, even if I only have the parameter for a client connection to the remote queumanager( port, host, cltconn channel)?
Gunter _________________ Gunter Jeschawitz
IBM Certified System Administrator - Websphere MQ, 5.3 |
|
Back to top |
|
 |
fjb_saper |
Posted: Sat Sep 24, 2005 7:09 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
What I meant to say Guenter is that once you are connected to the local queue manager any connection to the other qmgr should be known to the local qmgr as long as you try to connect to it in the same thread and while the connection to the local is still open.
One way to achieve this is a the definition of a client connection channel...
However if you do not need 2 phase commit I would suggest you only use client connections. This will allow you to use multiple connections in the same thread. If you need 2 phase commit and do not need to do any gets use a channel and remote queues of a default path to the other qmgr.
And there is always the possibility of using a Transactional Client....
Hope this clarifies a bit and does not add confusion...  |
|
Back to top |
|
 |
|