| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Cleint mode one day, server mode another - is it a Thermos? |
« View previous topic :: View next topic » |
| Author |
Message
|
| dgolding |
 Posted: Fri Jun 20, 2014 4:13 am Post subject: Cleint mode one day, server mode another - is it a Thermos? |
 |
|
Yatiri
Joined: 16 May 2001
Posts: 668
Location: Switzerland
|
One of our users has got a 3rd party app and is using it to make connections to their local queue manager. They now want to make a client connection to a remote queue manager, but instead of a server and client version of the executable, the vendor has supplied one single executable that "decides" whether to use server or client libraries, depending on whether the server libraries exist on the local system.
My question is, why in Gods' Name would anyone think this is a useful option? They want to make a client connection from this local machine but seems they are unable. I can only assume (unless the vendor is giving them a load of bollards) that it is loading libraries at run-time, complicating the code - why? Red Hat Linux btw, MQ6
P.S. A Thermos flask is a wonder of science - it keeps cold drinks cool one day and hot drinks warm the next. How does it know? |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Fri Jun 20, 2014 5:09 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Well, MA7K does this, but it does it by giving the user a switch to change mode at startup. (you point it at the relevant dll, one could presumably do the same thing with a .so or other unix library)
It's not unreasonable for the vendor to want to have, essentially, a single build process.
MS03 always had to compile the exact same code twice, once against server libs and once against client libs.
Granted, it was the same makefile (I think... (i didn't double-check)) and so it was, essentially, a single build process. But it's still two files to package and manage and document and instruct the end user on and support the end user failing to understand.
Ask them sweetly if this means they intend to only test their application in one configuration - either a server, or a client.
There's generally no reason a client-bound application would care if the queue manager was local or not. |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Fri Jun 20, 2014 5:17 am Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
I am a little surprised that you do not think the general concept is useful. MQ Development used to get frequent requests from customers to allow a single application to decide at connect time whether to do a local or client connection. It was always considered a real pain to have to ship two versions of the same program, one linked with the client and one linked with local bindings.
Recent versions of MQ do now allow an application to make a dynamic decision at connect time, prior to that, you are right, the application has to dynamically load the appropriate libraries. This is what my SupportPacs MO71, MO72,MA01 and MO03 all do.
The key thing, I imagine, is that the application should always have a parameter which allows you to override the default choice. ie. just because there is a local queue manager on the box doesn't mean that that is the thing you want to connect to.
Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Jun 20, 2014 5:27 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
And to put a different spin on the Thermos question.
An MQ queue manager has two distinct addresses. - The name of the queue manager
- A hostname/ip address, port, and SVRCONN channel name
If a user provides the first one, there's no way to make a client connection.
If a user provides the second one, there's no way to make a bindings connection.
If the user provides both, then the program is not properly validating it's input. |
|
| Back to top |
|
|
| dgolding |
| Posted: Fri Jun 20, 2014 5:38 am Post subject: |
|
|
Yatiri
Joined: 16 May 2001
Posts: 668
Location: Switzerland
|
Thanks for the replies. The issue is how to control it - our users clearly can't, there seems to be no clean way to make it client or server. That's why I was asking what is the point - simply link the compiled binary with server or client libraries, and you have two different executables - not rocket science and when you type a specific name in you KNOW what you are running. No guessing, no magic command line param or environment variable. One source code but linked twice.
Now they are stuck, they can't make the client connection to a remote queue manager as the program is forcing them to make a local server connection - because there is a queue manager already on the source machine. |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Fri Jun 20, 2014 5:42 am Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
As I say, any application providing this sort of selection ought to provide some sort of configuration parameter that allows you to choose the connection method. Are you certain they don't?
If we are certain that they don't then the next question is how do they determine that the local bindings is there? Do they look for an environment variable of some sort? Would it be possible to change this variable to fool the program into thinking there is no local bindings?
Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
