| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| CCDT Best Practice |
« View previous topic :: View next topic » |
| Author |
Message
|
| vivica12 |
 Posted: Wed Nov 12, 2008 2:01 pm Post subject: CCDT Best Practice |
 |
|
Acolyte
Joined: 13 Jul 2007
Posts: 58
|
I am beginning the implementation of a CCDT strategy at my work. I thought I would get some feedback on the plan, so that I don't have to change everything later 
IN my environment we have a shared MQ backbone, with many apps connecting. We also hope to implement SSL in the future. Based on this, we have one app per channel connecting to MQ. So for CCDT files, there are many channels to manage.
Here is my current plan.
1. On Server 1, mv the current AMQCLCHL.TAB file to a backup file
2. Create my SVRCONN and corresponding client conn
3. Create my second client conn on same server 1
4. On Server 2 create the corresponding SVRCONN for the 2nd connection
5. On Server 1 mv the new TAB file to a file named for the channel that it references
6. manage the files on a netapp share with the WAS environment to be used by connection factories
Anyone see any major flaws in that plan? I have read that the AMQCLCHL.TAB file is required to be present, but does it matter what's in it? I will say that we haven't always had one present, and we can still create channels. Does this pose a problem?
Thanks for any guidance, I"d rather learn now how best to manage this...then after I do it
_________________
Vivica - signing off |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Wed Nov 12, 2008 2:56 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9471
Location: US: west coast, almost. Otherwise, enroute.
|
One option is to have a single CCDT that has all client connection channel definitions for any/all clients to any/all qmgrs throughout your organization. This single CCDT can reduce admin confusion about which CCDTs go with which clients to which qmgrs.
I'm fond of creating an otherwise non-functional (no applications, no functional channels) qmgr whose sole purpose in life is to be the creator of the CCDT. From this qmgr, you export or share the CCDT.
I can see value in re-naming CCDTs with date/time/release kind of information for percolation to newer CCDTs if you have many of them; but if you can have a single CCDT shared on a SAN, then one will do for all. If you have many CCDTs, or you rename them, you will then need to have some method of validating that the new CCDT has replaced the previous one.
_________________
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 |
|
|
| PeterPotkay |
| Posted: Wed Nov 12, 2008 5:18 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
With one monster channel table you can't have App A connect to QM1 over SVRCONN.CHANNEL.A while App B connects to QM1 over SVRCONN.CHANNEL.B.
You need a channel table per app.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Wed Nov 12, 2008 6:20 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| PeterPotkay wrote: |
| ...You need a channel table per app. |
Agree, and I have used this technique in practice.
If the CCDT contains unique channel names and qmgr names for all the application's environments (dev, test, uat, preprod, prod etc) the file can be packaged with the application. The only requirement is that the app connect to the correct qmgr name for the environment it is running in.
There should also be network demarkation of all environments, such as firewalls, separate DNS etc. so that accidental cross-environment connection cannot occur. But in a properly designed app the actual queue names are also different for each environment (well at least for production), so that even accidental cross-environment connection will not corrupt production data.
_________________
Glenn |
|
| Back to top |
|
|
| vivica12 |
| Posted: Thu Nov 13, 2008 11:01 am Post subject: |
|
|
Acolyte
Joined: 13 Jul 2007
Posts: 58
|
Thanks for all the good comments. I am going to consider the qmgr dedicated to managing the clntconn's, that may be helpful.
In our environment we want to keep the files seperate from the code. Whenever we have changes that involve code, it takes so long. If we configure these at an infrastructure level (ie connection factories pointing to local file systems), then if there are changes, it's not a code change. This is very helpful I think, especially if we grow and go from 2 qmgrs to 3+ etc.
I read that MO72 support PAC can be helpful in managing CCDT files, but in reading about het support PAC i didn't really see why. Anyone have any experience with it? Is it helpful in this case?
Also, any thoughts on whether there has to always be a AMQCLCHL.TAB file present for the qmgr? Docs say it has to be there, but in practice I haven't seen why...
thanks for your feedback, it's nice to know I"m atleast headin the right direction.
_________________
Vivica - signing off |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Thu Nov 13, 2008 12:12 pm Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
With MO72, you can manage the CCDT without a QMGR. You just need to point the environment variable MQCHLLIB to the directory that contains the CCDT. You can also point MQCHLTAB to the file name if you changed it from the default.
Note that at V6, you cannot copy an AMQCLCHL.TAB into a QMGR's directory can start modifying it.
It is the one that came with the QMGR and whoa is be to you that messes with it outside runmqsc or the MQ Explorer. I think runmqsc should allow you to manipulate the CCDT without a QMGR but there are some SSL things that require one... Of course, that is only important if you use SSL. There was a bug about SSL on the CLNTCONN with MO72 but I think it has been fix (it was for the private version I got when I noted the problem to the author).
Another interesting trick with CCDT is the concept of QMGR Grouping. It is where say two QMGRs have SVRCONNs like QMGR.A.SVRCONN and QMGR.B.SVRCONN. Then you make matching CLNTCONNs but for both you specify the QMGR as GROUP.QMGR. If the client application trys a QMGR name of '*GROUP.QMGR', then it will connect to one of the QMGRs. If the one it normally connects to (and in V6 that will be the lexically first channel name) is not available, it will try to connect to the next one.
It is sort higher availability, if I dare to say such a phrase with this.
Dale Lane describes this better then me here: http://hursleyonwmq.wordpress.com/2007/02/26/client-connection-wildcards/
If you read, "What's new in MQ V7", you will see a slight change in the behavior. |
|
| Back to top |
|
|
| vivica12 |
| Posted: Fri Nov 14, 2008 8:43 am Post subject: |
|
|
Acolyte
Joined: 13 Jul 2007
Posts: 58
|
I read through the items about using a qmgr group name, vs a * etc. I know this value would be set in the CLNTCONN creation as the QMNAME( ) option. Correct?
In our configuration, atleast the pilot, we have chosen to leave that field blank. Again, our major goal is to have failover -- improve uptime etc.
So we have Server A and B.
Server A has -SVRCONN CHL1A, CLNTCONN CHL1A, CLNTCONN CHL1B
Server B has - SVRCONN CHL1B.
Both CLNTCONN's have an empty QMNAME( ) field. File CHL1.TAB has been created and moved to the WAS machine.
In WAS we have set the JMS properties as follows:
JMS Connection Factory:
Queue Manager: [blank]
Channel: [blank]
Custom Property:
CCDTURL: file:///www/iaf/mq_ccdt/CHL1.TAB
QMANAGER: *
JMS Queue:
Queue Manager: [blank]
Channel: [blank]
In this case we are using the * option to reference any qmgr, and with the QMNAME() field blank, it works. We know it choses the connection based on alphabetical order of the channel name. So primary would always be CHL1A, connecting to SERVER A.
Does anyone see any negatives with this? It works in the testing we've done, and it allows us to easily add SERVER C, with CHL1C to the file if needed. Is it better practice to fill in that QMNAME() filed with a GROUP option?
_________________
Vivica - signing off |
|
| Back to top |
|
|
| vivica12 |
| Posted: Fri Nov 14, 2008 8:47 am Post subject: |
|
|
Acolyte
Joined: 13 Jul 2007
Posts: 58
|
Another question:
I thought I read that when using a CCDT file via WAS, if SERVER A fails and the app connects to SERVER B....it will attempt the reconnect to SERVER A at some interval. Is this true? Will there have to be some manual intervention to ensure traffic fails 'back' to your primary?
In testing, I found then when SERVER A fails, it goes to SERVER B..if I don't use SERVER B for awhile and the SERVER A issue is resolved..it will reconnect to SERVER A. But I'm wondering if there is a heavily used app with many connections if it will every re-try SERVER A (so far i don't seem to have hit that threshhold to retry A)
thanks
_________________
Vivica - signing off |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Fri Nov 14, 2008 12:07 pm Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
Well, I'm not familar with how WAS works with this.
I think the * on the QMANAGER will connect to the first one that answers regardless of what is in the CLNTCONN QMNAME().
There is a difference in the behavior between V6 and V7.
On V6, it will only retry from the first one listed if the connection is new. The main issue with this is if the application makes a request on one QMGR, looses its connection and reconnects to another QMGR, it will never get its response. I think that would be a very rare case. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Nov 14, 2008 6:06 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Quote: |
| Does anyone see any negatives with this? It works in the testing we've done, and it allows us to easily add SERVER C, with CHL1C to the file if needed. Is it better practice to fill in that QMNAME() filed with a GROUP option? |
It really depends on the scope and usage of your CCDT. If you want to use the same table for different apps and you want each app to use its own channel(s) I would advise you to set a dummy qmgr name into the client connection qmgr like ... the appname?
Then using *appname for the qmgr name in JNDI would only cycle you through the available connections for the app.
Have fun 
_________________
MQ & Broker admin |
|
| 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
|
|
|
|
