| Author |
Message
|
| PeterPotkay |
 Posted: Fri May 01, 2009 7:34 am Post subject: QCFs and Destinations and an * for the QM Name |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
I'm working with a customer's .bindings file in MQ Explorer. It has about 30 queue objects and 3 QCFs. The three QCFs refer to 3 different QMs right now, but the app's queues will all be going to the same new QM. They each have a different SVRCONN channel name as well.
When all the MQ Queues and SVRCONN channels are created on the new QM, how do the MQQueue objects for AppA know to use the QCF for AppA(that has the AppA SVRCONN channel) and AppB knows to use the AppB QCF? I guess the MQQueue's QueueManager attribute is used to find the correct QCF when multiple QCFs exist in the bindings file. Is this correct? If yes, each QCF in the .bindings file needs to have a unique QM name?
So I can tell them to break this out into 3 separate .bindings file, or I can tell them to use a new common SVRCONN channel on the new QM called AppA.AppB.AppC, and the .bindings file will then only have one QCF.
What if I want them to use an * in the Queue Manager property for the QCF? MQ Explorer won't let me put an * in the QM property of the MQQueue, although I can leave it blank. If the QM property of the MQQueue is blank, that means there can only be one QCF in the .bindings file, right? And that QCF can have * for the QM name?
We will be trying this out, but wanted to run this by you guys to see if there was something I was missing.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Fri May 01, 2009 7:40 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
JNDI is a name-based mapping. An app uses QCFA because it asks for QCFA by name.
You can change all three QCFS to point to the same qmgr using the same SVRCONN (or a brand new one) without changing anything else and it should all work just the same. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri May 01, 2009 7:50 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| mqjeff wrote: |
JNDI is a name-based mapping. An app uses QCFA because it asks for QCFA by name.
You can change all three QCFS to point to the same qmgr using the same SVRCONN (or a brand new one) without changing anything else and it should all work just the same. |
But I want to use an * or blank for the QM name in the QCF, so that means there can only be one QCF like that in a .bindings file? Because the only way (?) to tie a MQQueue to a QCF is by the QM name specified in the MQQueue and the QCF.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| markt |
| Posted: Fri May 01, 2009 8:50 am Post subject: |
|
|
Knight
Joined: 14 May 2002
Posts: 508
|
There is no connection between a Queue definition (Destination) in JNDI and a QCF definition.
If you put a QMNAME in a Q definition, it's equivalent to using both in an MQOPEN - ie it'll resolve to the appropriate xmitq. Nothing more.
Using the QCF is (approximately) the same as MQCONN. Using the Q is (approximately) the same as MQOPEN. Both are independent, and applications have to be coded/configured to use both names. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri May 01, 2009 12:07 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| PeterPotkay wrote: |
But I want to use an * or blank for the QM name in the QCF, so that means there can only be one QCF like that in a .bindings file? Because the only way (?) to tie a MQQueue to a QCF is by the QM name specified in the MQQueue and the QCF. |
Don't use a * JNDI is not a CCDT!.
You are looking at JNDI. The manual specifies that if no qmgr name is present on the destination the queue resolution will go as follows (from memory you might want to look it up)
- Treated as cluster queue
- the qmgr from the connection is used
I would recommend to not use a qmgr on the destination unless you want to bypass a remote queue and use the Destination as queue in a qmgr you are not connected to and is not in a cluster. This one should have a qmgr name on it...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri May 01, 2009 12:47 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| markt wrote: |
There is no connection between a Queue definition (Destination) in JNDI and a QCF definition.
If you put a QMNAME in a Q definition, it's equivalent to using both in an MQOPEN - ie it'll resolve to the appropriate xmitq. Nothing more.
Using the QCF is (approximately) the same as MQCONN. Using the Q is (approximately) the same as MQOPEN. Both are independent, and applications have to be coded/configured to use both names. |
Of course. Shows how much I program in JMS. Vitor and I are kindered spirits.
The JMS app uses the QCF for the MQCONN, and the MQQueue for the MQOPEN. The MQQueue's QM property is for the MQOD's QM value, and has no relationship or dependency on the QCF's QM Name property.
I had a developer insisting that the 2 QM values needed to be the same, and since my JMS skills weren't strong enough to fight back....now I know better.
FJ, I want to use an * for the QCF's QM Name so that during DR we can repoint the DNS name of the destroyed MQ server over to the IP of the corresponding MQ server in the DR site, where the QM name is different, but all the queues and channels are the same. Having different QM names allows us to have both QMs on the network at all times. Having the apps use an * in the QCF allows them to use the same bindings file whether its production or DR, and not need to make any MQ config changes after a DR, other than to reconnect after we say go. If apps want to have a DR specific bindings file they can, and they can then code the DR QM name DR hostname in the DR .bindings file. My requirement was to come up with a solution that allowed apps to flip to the DR MQ infrastructure without making a config change.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat May 02, 2009 6:13 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Quote: |
| FJ, I want to use an * for the QCF's QM Name so that during DR we can repoint the DNS name of the destroyed MQ server over to the IP of the corresponding MQ server in the DR site, where the QM name is different, but all the queues and channels are the same. Having different QM names allows us to have both QMs on the network at all times. Having the apps use an * in the QCF allows them to use the same bindings file whether its production or DR, and not need to make any MQ config changes after a DR, other than to reconnect after we say go. If apps want to have a DR specific bindings file they can, and they can then code the DR QM name DR hostname in the DR .bindings file. My requirement was to come up with a solution that allowed apps to flip to the DR MQ infrastructure without making a config change. |
You don't need multiple CF's for that. You just need one and specify the CCDT URL ("file://host/path/CCDTfilename") in the .bindings for that CF.
I would even go as far as specifying a dummy qmgr name per app. If your channel names are done right you should have a primary and a failover channel/qmgr for your connection... but then you already know how to play the channel table game...
On the other hand you can have one CF defined per app and the qmgr value (*dummy) set in the CF setup. This avoids you having to specify the qmgr name (*dummy) at runtime. The different CF's you define could differ only by the qmgr name (still using a CCDT)...
Have fun.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sun May 03, 2009 2:55 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
I did consider CCDTs. At first I said they won't work, because they work too well. If the Primary QM is moving from Node A to Node B of its hardware cluster, the CCDT will start sending apps to the Secondary QM, which is supposed to be for DR only, and not because the Primary QM is N/A for whatever reason for however long. I could have just kept the SVRCONN channels on the DR QMs stopped until I started them as part of my DR steps.
A couple of problems with this.
The powers that be didn't like that network traffic would be going to the DR site automatically (never mind that the connections would fail due to the stopped SVRCONNs). DR Failover is a manual decision. Period. OK.
The DR solutions all areas had to come up with had to be as transparent as possible to the apps. They are having a cow just changing the QM name to an *, never mind introducing CCDTs. For none JMS apps the introduction of a CCDT is a bigger change involving setting evnvironment variables.
I support hundreds of apps. The thought of making hundreds of CCDTs...oh boy.
But were I designing a brand new MQ Infrastructure for some new apps, yes, CCDTs would be the way to go with stopped SVRCONNs at the DR site. Actually I would push for an infrastructure where both data centers are active and all work is being load balanced with CCDTs and MQ Clustering. If one goes down, the other picks up the slack automatically and transparently.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun May 03, 2009 8:40 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Well it looks like you're SOL.
As the CCDT is not allowed you have a few choices:
- You need to have the app recognize 2 different CF's and choose a primary and a failover (for when the primary is not available). In case of a client connection the qmgr name is not required. Leave it blank (no *)
- In case of a bindings connection you will need the exact qmgr name in the CF. If left blank it goes to the default qmgr on the box. Again no * allowed.
- Concerning the destinations: I would probably make sure that all the needed destinations are defined i.e. have a queue on the qmgr you are connected to. Do not populate the qmgr in the destination (leave blank, set to space). If using the uri form use "queue:///QNAME?attribute=value"
Make sure all default paths are defined in the QM network so you will have no trouble with a JMSReplyTo destination.
- The only case where I would potentially define a qmgr on a destination is if
a) There is only one possible instance of the destination
b) The network is set up in such a way that the alternate destination qmgr has an alias to consume messages meant for the primary. Changes in the routing will then determine whether the message goes to the primary or the alternate qmgr.
Again no * in the qmgr name for a destination. This is not a valid value.
In JMS the absence of a value (spaces) for the qmgr in the destination is interpreted as the destination in the qmgr you are connected to or a cluster queue. As you create your producer off a session and the session off a connection you have always a known qmgr you are connected to at runtime.
So for your JMS apps: Define your destinations once only and leave the qmgr blank on the destination.
And by the way I would not make 100s of CCDTs for 100s of apps. Group what makes sense into 1 CCDT and have different apps use different dummy qmgr names in the CCDT. Then connect using *dummy. Easy mnemonic use the appname as dummy...
| Quote: |
| The DR solutions all areas had to come up with had to be as transparent as possible to the apps. They are having a cow just changing the QM name to an *, never mind introducing CCDTs. For none JMS apps the introduction of a CCDT is a bigger change involving setting evnvironment variables. |
Now imagine how much more of a Cow they are going to have realizing they need to change code. The only way to do this seamlessly is to shift all of it to DR, not just the app but also all the connected apps.
If your main qmgr goes AWOL and you need to switch to DR you need to switch all your connected apps to DR!
The only way this can be avoided without any code change / design change is with a CCDT in your CF setup in JMS.
With your current setup I would suspect that you have different configurations for normal setup and DR setup.(JNDI). All other capabilities will involve either addional coding (the app must be able to recognize multiple CF's) or configuration changes in JNDI that would typically mean you have to stop the Web server and restart it. Best case scenario: you have multiple CF's defined in JNDI and do a hot deploy of the app in case of DR. (no need to restart the app server, the new resource mapping happens in the deployment descriptor)
I guess the lesser COW for JMS client apps is still the CCDT.
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sun May 03, 2009 9:26 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
We are only dealing with MQ Clients.
I think the easiest thing is not a CCDT but to have all the apps use * for
the QM name for the Connection Factory. Very simple change on their part.
To have them use a CCDT is not that much more complicated, but it does cause me to make lots of CCDTs, or make a gigantic one which then becomes a pain to maintain. And for non JMS apps switching to using a CCDT is a little more work. At the very least they know have to set environment variables and at the worst they have to dumb down their MQCONNX call. Code changes - not good. But simply using an * for QM name is an easy tweak, assuming they didn't hard code the name in the code, which I doubt they would since we use different QM names between DEV, QA and PROD. And now DR.
When a DR is declared, I change the DNS Name for the PrimayMQ_Server to point at the IP for the DRMQ_Server. Since the apps are using * for the QM name, they will reconnect to the DR QM and be on their way. This repointing only happens if DR for the company is declared and EVERYTHING is moving to the DR site.
I do agree that for a new infrastructure with new apps a CCDT is preferred, but I don't have that luxury.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon May 04, 2009 2:13 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Have you tried it out? Does the '*' work?
In my experience it should just not be populated i.e. spaces
If there is a value in the qmgr name the it gets checked against the information from host, channel port, when connecting through the qcf.
Like I said for Destination (queues) there should be no value there either.
Don't know where you got the notion of using a "*" without using a CCDT from.
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
