| Author |
Message
|
| fmv0202 |
 Posted: Wed Dec 13, 2006 5:03 pm Post subject: AMQ9520: MQClient + Multiple Remote Queue Managers |
 |
|
Apprentice
Joined: 13 Dec 2006
Posts: 28
|
Hello,
First and foremost, this is the best site on the web for this content!!! I am new to the world of WBI + MQ and currently have a delimia that I am trying to figure out. Here is my background information for the given scenario that I am trying to determine:
MQSeries Info:
Name: WebSphere MQ
Version: 530.8 CSD08
Resources I've been using up to this point:
MQClient pages(124,125,128,153)
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/books/csqzaf05.pdf
which states:
Define your client-connection and server-connection channels on one queue manager only, including those channels that connect to a second or third queue manager.
Assumption:
Both srvrconn/clientconn channels for each queue manager have been created in a SINGLE Queue Manager, and the corresponding TAB file for that queue manager has been distributed to the client side. The Queue managers are not CLUSTERED, which means queue manager 1 and 2 are foriegn to each other which to my knowledge means that in order for QMGR1 to talk with QMGR2, a remote definition must be supplied.
QMGR is listening, QMGR2 is listening.
Question is:
When they state (including those channels that connect to a second or third queue manager), do they mean that ALL communciations from a first queue manager to the second queue manager must be supplied? By that, do I need a transmission queue available for the communication of QMGR1 if QMGR2 is not clustered nor local to QMGR1? Or is enough to supply the srvrconn connection details to the existing client and that client will be able to communciate to QMGR2?
I appreciate any input you might have to point me in the right direction.
 |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Wed Dec 13, 2006 6:01 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
MQCONN returns a single connection to a single queue manager.
It is almost never necessary for a single application to connect to more than one queue manager simulatneously. Most applications can connect to one queue manager, and allow MQ network communications (queue manager to queue manager) to move messages to the appropriate receiver.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fmv0202 |
| Posted: Wed Dec 13, 2006 6:31 pm Post subject: |
|
|
Apprentice
Joined: 13 Dec 2006
Posts: 28
|
Thanks Jeff for your prompt reply.
This is not my intended choice either from what I've read on the forum and within the manuals. This is actually a circumstance of inheritance, and I don't mean Object Oriented Design. As crazy as this may sound, its actually the best solution I have given the current circumstances with what I'm working with... 
So based on what we have discussed here, my options at this point are:
Option 1)
To use a single queue manager which intern would communicate to the coressponding remote queue managers via the traditional route with sdr/rcvr channels. Which you have stated.
Option 2)
If the MQCONN command could be replaced with the MQCONNX command. Not sure if this command would allow me to perform the necessary operations of the mq client communicating to mulitple remote queue managers or not...
Option 3)
Look into setting up a queue manager cluster which would be available to the MQClient and would therefore provide the necessary scope to communicate to all queue managers within that cluster.
Which do you feel would make the most sense based on your past experience?
Agian, I'm a newbie so I'm all about people who have been there done that and have the T-Shirt. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Dec 13, 2006 6:36 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
MQ clustering doesn't change the nature of the return value from MQCONN.
MQCONNX is the same as MQCONN, it just gives the program more control over the channel definition, rather than leaving that up to the environment.
A single client application can establish connections to many queue managers. But it shouldn't.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fmv0202 |
| Posted: Wed Dec 13, 2006 7:04 pm Post subject: |
|
|
Apprentice
Joined: 13 Dec 2006
Posts: 28
|
Jeff,
Other then the obvious of poor design and bad architecture being driven by external circumstances, what are the risks associated with this?
Going of the top of my head here but...from a high level perspective
1) Single Point of failure
2) Depedencies associated with foriegn queue managers and the local queue manager...meaning if QMGR1 is down QMGR2 isn't doing anything. This implies, channels, network issues or connectivity issues.
3) ???
This is a bad decision I realize but I must have some convincing information before I can propose an alternate more attractive solution to my superiors.
Thanks Again!! |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Dec 14, 2006 12:06 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| fmv0202 wrote: |
Going of the top of my head here but...from a high level perspective
1) Single Point of failure
2) Depedencies associated with foriegn queue managers and the local queue manager...meaning if QMGR1 is down QMGR2 isn't doing anything. This implies, channels, network issues or connectivity issues.
3) ???
|
My 2 cents...
You should try and separate availability issues from connectivity issues. If you browse through the Clusters section of this forum you'll see much discussion from many people who have tried to use queue manager clustering as a high-availability failover solution. It's not meant for that and solutions involving that tend to be dubious. You should consider the architecture of your message flow, build that and then put in additional HA solutions to eliminate points of failure.
Turning to your specific points, you can use client connection tables to allow a client to connect to an alternative queue manager in case of failure. Look though the Clients manual again - it's extra channels in the TAB file. You do need to code reconnection logic in your application to trap the failure, but it does work.
Channels are for the most part self-healing (once the network is back). It's not as much of a problem as it seems.
Build a topology according to your requirements.
(And if you want to post more specific requirements you might get more specific answers. But it sounds like you have a traditional QMGR1 -> QMGR2 set up).
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fmv0202 |
| Posted: Thu Dec 14, 2006 6:26 am Post subject: |
|
|
Apprentice
Joined: 13 Dec 2006
Posts: 28
|
Thanks Vitor! This is actually a case or should I say an attempt to make use of an existing MQ Client installation. So I have 2 different queue managers, who have to completely independent roles. Which means, we are trying to reuse a MQClient that has already been configured for application 1 which is being called from an Oracle Stored Procedure.
The theory is that they will pass a call and specify a queue manager as part of a parameter and that call will invoke the corresponding connection to the remote queue manager. I guess I'm leaving this kinda stuff out because it just clutters the point.
This is why I haven't looked into the MQCHLIB or MQCHLTAB options because I believe this is a solution that connections to only 1 application at a time, where as, in my case, I need to have this client communicating to mulitple queue managers. Maybe I'm missing something though...
The thought is by using a channel table definition file that contains multiple queue manager's information, that somehow, magically, it will know how to talk to all the queue managers from a single client using this channel table file that contains these multiple connection information.
It is able to communicate to Application 1, but reports the AMQ error on Application 2. This IS the traditional QMGR1, QMGR2. QMGR1 and 2 are not clustered nor do they know about each other by traditional means (MCA, XMITQ) etc...
As for the message flow, I think I understand what I need to do.
Is the purpose of the MQClient intended to be one-to-one. Meaning was it designed to have one MQClient installation PER application. Which could mean, we need to have 2 MQ client installations/configurations for two DIFFERENT applications? Or can we somehow re-engineer the one to communicate to 2 different remote MQ queue managers or servers.
This seems like a simple request...but the term "client" is confusing me as to what the capabilites of this thing are. I'll keep reading but any input would be great. |
|
| Back to top |
|
|
| bbburson |
| Posted: Thu Dec 14, 2006 6:35 am Post subject: |
|
|
Partisan
Joined: 06 Jan 2004
Posts: 378
Location: Nowhere near a queue manager
|
| fmv0202 wrote: |
This is why I haven't looked into the MQCHLIB or MQCHLTAB options because I believe this is a solution that connections to only 1 application at a time, where as, in my case, I need to have this client communicating to mulitple queue managers. Maybe I'm missing something though...
The thought is by using a channel table definition file that contains multiple queue manager's information, that somehow, magically, it will know how to talk to all the queue managers from a single client using this channel table file that contains these multiple connection information. |
I think you are missing something. MQCHLLIB and MQCHLTAB are exactly what you need for a client to be able to connect to multiple queue managers.
On EACH queue manager you need a SVRCONN channel that the clients will connect to.
On ONE queue manager you define CLNTCONN channels that describe ALL the SVRCONNs for the various queue managers. Export the resulting AMQCLCHL.TAB file (in the queue manager's @ipcc subdirectory) to the client machine and define MQCHLLIB and MQCHLTAB to point to it. |
|
| Back to top |
|
|
| wschutz |
| Posted: Thu Dec 14, 2006 6:43 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
and a little more...
you only ever need one installation of the WMQ client software per machine.
In your amqclchl.tab file, you have multiplte clntconn defs, of the form:
def chl(ca) chltype(clntconn) conname(qma.host) qmname(qma)
def chl(cb) chltype(clntconn) conname(qmb.host) qmname(qmb)
your WMQ client chooses one of these definitions based on MQCONN call:
mqconn("qma" ....) tries to use channel "ca".
(make everything uppercase to eschew obsfucation)
_________________
-wayne |
|
| Back to top |
|
|
| fmv0202 |
| Posted: Thu Dec 14, 2006 6:49 am Post subject: |
|
|
Apprentice
Joined: 13 Dec 2006
Posts: 28
|
| Wow... You guys are good!! Okay, I'll try out what you've stated in this thread, I'm sure it will work but I'll communicate it back to everyone as POC. Thanks to all your input!! |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Dec 14, 2006 7:09 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| fmv0202 wrote: |
This is why I haven't looked into the MQCHLIB or MQCHLTAB options because I believe this is a solution that connections to only 1 application at a time ...
The thought is by using a channel table definition file that contains multiple queue manager's information, that somehow, magically, it will know how to talk to all the queue managers from a single client using this channel table file that contains these multiple connection information.
|
The 2 environment variables you quote are how channel tables are referenced! 
And there's nothing magical about how a single client works out how to talk to multiple queue managers; it uses the method described in the Clients manual. 
Trust me - it works.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fmv0202 |
| Posted: Thu Dec 14, 2006 8:07 am Post subject: |
|
|
Apprentice
Joined: 13 Dec 2006
Posts: 28
|
Guess what....
IT SOOO WORKED!! You guys ROCK!!
Thanks For Everything!!
|
|
| Back to top |
|
|
|
|
