| Author |
Message
|
| velocity |
 Posted: Tue Sep 15, 2009 11:43 am Post subject: MQ Client connecting to two QMs |
 |
|
Centurion
Joined: 30 Nov 2007
Posts: 126
|
Hi Guys,
I have a situation where MQ client connects to two QMs with SVRCONN-CLNTCONN pair. To get that connection going, there will be two client connection defn table files generated on the two QMs, that need to be ftpd to the MQ client. How to get this working? Will there be a conflict? or should I just change the names of the file and ftp them to the MQ client box.
Pls advice. |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Tue Sep 15, 2009 11:53 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
You only need 1 channel table, that can be created on any QM.
Designs that call for an app to connect to 2 or more QMs at the same time are suspect.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| velocity |
| Posted: Tue Sep 15, 2009 12:01 pm Post subject: |
|
|
Centurion
Joined: 30 Nov 2007
Posts: 126
|
| Quote: |
| You only need 1 channel table, that can be created on any QM. |
The channel tab file will contain the client conn info. Each QM will generate a unique file with the clntconn name.(There will be one clientconn channel name in each file and the names will be different ). How will one file suffice?
| Quote: |
| Designs that call for an app to connect to 2 or more QMs at the same time are suspect. |
Why is this suspect. I dont quite get it. Are you saying the client cannot open a connection with two queue managers at the same time?
Please explain when you get a chance. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Sep 15, 2009 12:15 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| There's no reason to create clntconns on more than one QM. |
|
| Back to top |
|
|
| velocity |
| Posted: Tue Sep 15, 2009 12:26 pm Post subject: |
|
|
Centurion
Joined: 30 Nov 2007
Posts: 126
|
| Quote: |
| There's no reason to create clntconns on more than one QM. |
Cool! But then how will the client know about QM2 if I the MQ client box has the AMQCLCHL.TAB file from QM1 on it. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Sep 15, 2009 12:32 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| velocity wrote: |
| But then how will the client know about QM2 if I the MQ client box has the AMQCLCHL.TAB file from QM1 on it. |
Because the file contains details of all the possible connections. A lot of site use a single queue manager to create the AMQCLCHL.TAB for all their clients.
And again, any design that calls for connections to more than one queue manager simultaniously is suspect. Coding such a client requires special handling due to the client connection rules.
Think carefully before going down such a route. Does the client application really need to connect to multiple queue managers, or does the designer just think it does because they don't get WMQ?
If however you mean the more common model of "connect to whichever of these 2 queue managers is available" then this is described in the clients manual. There are also multiple posts on this type of design in here; the search facility is your friend.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Sep 15, 2009 1:59 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
What is the business requirement that the client app connect to two qmgrs? Will the app attempt Unit-of-Work processing (comit/backout) prcessing?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| velocity |
| Posted: Wed Sep 16, 2009 2:33 pm Post subject: |
|
|
Centurion
Joined: 30 Nov 2007
Posts: 126
|
| Quote: |
| What is the business requirement that the client app connect to two qmgrs? |
The client app communicates with applications connected to each of the two queue managers.
| Quote: |
| Will the app attempt Unit-of-Work processing (comit/backout) prcessing? |
I can definately have the app folks do the above if this is a solution to the above problem.
Please advice further. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Sep 17, 2009 5:19 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
Bruce2359 asks: Will the app attempt Unit-of-Work processing (comit/backout) prcessing?
Velocity replies: I can definately have the app folks do the above if this is a solution to the above problem. |
WMQ supports UofW (transaction) processing based on a single MQCONNection handle to a single qmgr; thus, you app cannot do unit-of-work processing encompassing changes on two (or more) qmgrs objects. Your app developer will need to manage transaction comit/backout in the applicatin code.
So, will the app try to connect to two qmgrs at the same time (concurrently)? Or one at a time?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Sep 17, 2009 5:25 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| velocity wrote: |
| Quote: |
| What is the business requirement that the client app connect to two qmgrs? |
The client app communicates with applications connected to each of the two queue managers. |
This doesn't mean, in any way, that the client app needs to be connected to EITHER of the two queue managers.
It merely needs to be connected to SOME queue manager which is then connected to the two queue managers that the apps are connected to.
The ONLY reason you EVER need a single app connected to MORE than one queue manager is if the two queue managers CAN NOT be connected to each other directly or indirectly.
There are very few real scenarios where this is necessary - an app acting as a security bridge between hard network zones is one such. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Sep 17, 2009 5:39 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| There are very few real scenarios where this is necessary... |
I agree. It is a frequent leap of illogic for new-to-mq developers to think that if my client app can connect to one qmgr, why not two? While this is technically possible, there are some restrictions.
The big restriction is that UofW processing is limited to one connection handle, and each qmgr connection has its own connection handle.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
|
|
