| Author |
Message
|
| kevinf2349 |
 Posted: Thu Jan 06, 2005 1:04 pm Post subject: Multiple Clients channels from one machine |
 |
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
Hi
We are about to roll out a new MQ enabled application. The application uses a MQ Client to connect to a server. Some of the recipients of the new application already have an application clienting to another server.
I know what needs to be done, and how to do it, in order to facilitate this but my questions is more one of best practices.
What are the pros and cons of defining all of our client channels in one amqclchl.tab file and rolling this out (apart from the security side of things that is).
Do other sites keep a 'selection' of chltabs or do they customise the definitions depending on need?
I am open to all suggestions/recommendations as this is a pretty clean slate here. This is our first encounter of this 'clash'. |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Thu Jan 06, 2005 1:20 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Actually, the documentation specifically recommends that you do this.
It is very clear that it is not possible to manually merge channel tables, and also clear that you can't have more than one on a machine (although this can be fudged a bit with environment variables, I think).
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Jan 06, 2005 2:09 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
While it is true you cannot merge channel tables, you can make 100 CLNTCONN channels all on 1 QM that match up to SVRCONNs on 100 different QMs. This will give you a single channel table, but I don't recommend that.
Usually you want channel tables set up so that the app can issue an MQCONN with a blank QM name, and then the channel table handles which QM they actually get. If you put all 100 in 1 channel table you have lost control.
We have 3 pairs of QMs, each pair serving a particular testing environment. A tester might want to fire up the app to test in environment 1 (E1), or E2, or E3. The app is coded to connect to a blank QM, so that it could connect to QM1 or QM2 in whichever environment it was in. The channel table would insure that if QM1 was down, it would go to QM2.
But how to insure that a tester that wants E1 would only get QM1 or QM2 from E1, and not E2, or E3?
We made 3 separate channel tables for each environment, and put them all on the testers' PC (E:\ChannelTablesAll). We set the MQEnvironment variables as MQCHLLIB=E:\ChannelTable\Current\ and MQCHLTAB=TheCurrentChannelTable.TAB
We then created 3 bat files for them, named E1, E2, or E3. They clicked on whichever environment they wanter to test. The bat file would fire up the app, but before it did, it would copy the appropriate channel table from E:\ChannelTablesAll into E:\ChannelTable\Current\TheCurrentChannelTable.TAB.
When there app issued MQCONN, it would look to the system variables which pointed it always to E:\ChannelTable\Current\TheCurrentChannelTable.TAB. But that file's contents would be the channel table info for E1, E2 or E3, depending on which bat file was originally clicked.
Been working great for years. In actuality, we have more QMs and more testing environments, but the above should get the concept across.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Thu Jan 06, 2005 5:56 pm Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
Jeff,
Thanks for the response. 
Peter,
That sounds like a pretty neat arrangement.
What my problem would probably be is with the (l)users natrual instinct to do it wrong and connect to the wrong queue manager for the wrong thing.
At our shop the first level diagnosis of any application issue is to set off a 5 alarm fire bell and shout 'the sky is falling, the sky is falling'...next we call the MQ guy....and guess who is the only MQ guy?
However, I still think it is a better approach than pooling very client channel into one table and it is definately worth giving some thought to. Thanks
Maybe I will write an MQ app launcher in .Net...kind of like a drop down pick list of which one they want, then set the MQSERVER and start then launch that app? That way the app goes untouched and it removes the need for the chltab.
Any thoughts? |
|
| Back to top |
|
|
| Nigelg |
| Posted: Fri Jan 07, 2005 1:15 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Jan 07, 2005 5:48 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| kevinf2349 wrote: |
| At our shop the first level diagnosis of any application issue is to set off a 5 alarm fire bell and shout 'the sky is falling, the sky is falling'...next we call the MQ guy |
This appears to be standard practice at most shops.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| KeeferG |
| Posted: Fri Jan 07, 2005 7:20 am Post subject: |
|
|
Master
Joined: 15 Oct 2004
Posts: 215
Location: Basingstoke, UK
|
I would recommend the use of MQCONNX for your client calls and remove the need for the definitions or enviornment variables. This was the recommended way to develop client applications for large scale deployments.
_________________
Keith Guttridge
-----------------
Using MQ since 1995 |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Jan 07, 2005 11:21 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
The MQSERVER variable does not provide failover for the app. You "hardwire" them to only go to QM1 on Server1. Maybe that's OK, maybe its not.
MQCONNX allows the program to pick and choose where it goes. But tetsters don't know how to change the program. I suppose you could make the program read an ini file that contains all the paramters needed by the MQCONNX call, and then you have to insure the correct ini file is where the program expects it. And the program will have to be coded to iterate through all the different values in the ini file so if QM1 is not availabkle, it will try QM2, then QM3, etc.
Channel tables make the programming a lot simpler.
If you need the app to connect to a primary QM, and if N/A, to a secondary, etc, thenm you need channel tables or the logic for MQCONNX in your program (with the supporting ini file that provides all the possible values).
If a single QM is all you got, and you don't mind a 2059 if the QM is N/A, the MQSERVER will work fine.
Remember channel tables are not supported by Java or .NET clients (as of 5.3 CSD08).
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| KeeferG |
| Posted: Mon Jan 10, 2005 5:17 am Post subject: |
|
|
Master
Joined: 15 Oct 2004
Posts: 215
Location: Basingstoke, UK
|
I forgot to add that you should use a configuration file as Peter suggests. This should be standard practice for all applicatiopn types unless security requirements intervene.
It is also true that you would need to code for the alternate connections however, this is usually a trivial affair.
Good luck with what ever approach you decide to use
_________________
Keith Guttridge
-----------------
Using MQ since 1995 |
|
| Back to top |
|
|
| olan022 |
| Posted: Thu Nov 10, 2005 8:08 pm Post subject: MQClient Question |
|
|
Acolyte
Joined: 17 Apr 2002
Posts: 50
|
| Quote: |
| The app is coded to connect to a blank QM, so that it could connect to QM1 or QM2 in whichever environment it was in. The channel table would insure that if QM1 was down, it would go to QM2. |
I have to say while I haven't yet fully played with MQ Client connections, I have done a fair amount of research in the manuals and this site and cannot seem to find anything specifically pointing to my issue. Peter's email gets close.
Put simply, my goal is simply to test load balancing of a clustered queue from an MQ client.
Two physically separate Qmgrs (QM1 and QM2) each with a clustered queue (Q1, for instance)
One MQ Client on a workstation.
I want to be able to connect to both Qmgrs and send to a queue called Q1 and have it load balanced between each clustered Q1 queue, such that i am not specifying a Qmgr when I am making the put.
I know MQSERVER won't get me there and the Channel Tab file appears to only go to the second Qmgr if the first is N/A. So, how do I load balance from an MQ Client?
fyi, I also know that clustering between only two Qmgrs is not necessarily ideal, but cannot readily think of other options for load balancing.
Thanks in advance. |
|
| Back to top |
|
|
| wschutz |
| Posted: Fri Nov 11, 2005 2:26 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
You can't do exactly what you want with MQ clients, unless you do two MQCONN's to the two queue managers and alternate putting the messages to them in your code. 
However, you CAN use the MQ client to connect to a queue manager in a cluster, and use normal MQ clusteriing from there to balance the work between two queues. If you have MQ V6, you only need two queue managers to do this, as you can connect to a queue manager that owns a clustered queue and still have messages round-robin to other queue managers that also own that same named clustered queue.
In MQ V5, you need to connect to a qmgr that DOESN'T have an instance of the clustered queue, and from there you could round-robin to other queue managers that do own the clustered queue.
The net is: MQ clustering from a MQ client behaves the same way as locally connected programs.
_________________
-wayne |
|
| Back to top |
|
|
| KeeferG |
| Posted: Fri Nov 11, 2005 3:45 am Post subject: |
|
|
Master
Joined: 15 Oct 2004
Posts: 215
Location: Basingstoke, UK
|
You can connect a client app to 1 qmgr and round robin between the instance of the cluster queue on both queue managers in MQ V5.3, however this would involve writing a cluster workload exit to NOT always select the local instance of the queue.
As wschutz suggests, it would be far simpler to add the third queue manager that does not contain an instance of the cluster queue and connect the client to that. Then you will be using the default cluster behaviour.
_________________
Keith Guttridge
-----------------
Using MQ since 1995 |
|
| Back to top |
|
|
| olan022 |
| Posted: Fri Nov 11, 2005 7:30 am Post subject: |
|
|
Acolyte
Joined: 17 Apr 2002
Posts: 50
|
| Quote: |
| If you have MQ V6, you only need two queue managers to do this, as you can connect to a queue manager that owns a clustered queue and still have messages round-robin to other queue managers that also own that same named clustered queue. |
Thanks for the replies.
wschutz (or anyone else that knows), where did you find this information? That would be great but I've been looking through V6 manuals and haven't found that specifically. |
|
| Back to top |
|
|
| wschutz |
| Posted: Fri Nov 11, 2005 7:35 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
Well, I'm sure its in the MQ cluster manual, but do a search on CLWLUSEQ in the infoctr.
_________________
-wayne |
|
| Back to top |
|
|
| olan022 |
| Posted: Fri Nov 11, 2005 8:32 am Post subject: |
|
|
Acolyte
Joined: 17 Apr 2002
Posts: 50
|
Wow. I see what you are talking about. Of course, these attributes must be all new with V6 as I don't see them under V5.3.
Now I need to whip up some V6 Qmgrs....
Thanks. |
|
| Back to top |
|
|
|
|
