Author |
Message
|
dudetom |
Posted: Mon Jul 16, 2018 1:33 am Post subject: Configuring separate CCDT files for each connection |
|
|
Apprentice
Joined: 29 Sep 2017 Posts: 45
|
As a requirement of our partner, We have to make MQ connections on different ports. And the requirement is to configure separate CCDT files for each port. All connections are made on one client application (one Process).
Because our client application is one Process I can't configure the below environment variables for each port separately.
How environment variables are set for configuring Client Channel Definition (This is .NET C#):
Environment.SetEnvironmentVariable("MQCHLLIB", @"C:\ProgramData\IBM\MQ");
Environment.SetEnvironmentVariable("MQCHLTAB", "AMQCLCHL<PORT>.TAB");
Our problem; We have to set these environment variables on connection level and not on Process or Global level. Any suggestions?
This question is also asked here:
https://stackoverflow.com/questions/51358635/configuring-separate-ccdt-files-for-each-connection
Thanks in advance |
|
Back to top |
|
 |
Vitor |
Posted: Mon Jul 16, 2018 4:41 am Post subject: Re: Configuring separate CCDT files for each connection |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
dudetom wrote: |
As a requirement of our partner, We have to make MQ connections on different ports. And the requirement is to configure separate CCDT files for each port. All connections are made on one client application (one Process). |
What's driving the requirement? What are you/they trying to achieve? Specifically, what's the problem with one single CCDT that describes all the connections?
Also what do you mean by "different ports"? Do you mean a single queue manager using multiple ports or multiple queue managers? It makes a key difference. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
dudetom |
Posted: Mon Jul 16, 2018 4:54 am Post subject: |
|
|
Apprentice
Joined: 29 Sep 2017 Posts: 45
|
Thanks for replying Vitor, see below:
Their requirement: The application must not rely on the CCDT to load-balance the connections to the Queue Managers, as CCDT doesn’t guarantee connections will be established to all Queue Managers. The application must explicitly create the connections against the queue managers, using 1 unique CCDT for each QM.
And for the other question: I don't know answer immidiately, but I think there is one QM on each port. |
|
Back to top |
|
 |
Vitor |
Posted: Mon Jul 16, 2018 5:33 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
dudetom wrote: |
Their requirement: The application must not rely on the CCDT to load-balance the connections to the Queue Managers, as CCDT doesn’t guarantee connections will be established to all Queue Managers. The application must explicitly create the connections against the queue managers |
Ok. Fair point. So the application is responsible for connecting to each of the queue managers. Odd, but not unreasonable.
dudetom wrote: |
using 1 unique CCDT for each QM. |
I still don't see why you can't have 1 specific connection for each possible queue manager in a single CCDT, with the application still connecting to each queue manager as described above.
dudetom wrote: |
And for the other question: I don't know answer immidiately, but I think there is one QM on each port. |
This would absolutely be the normal case, but the only reason I could think of that would require individual CCDTs is if they had a single queue manager with multiple listeners. This would hose up the name resolution if you used a single CCDT for all the connections. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
dudetom |
Posted: Mon Jul 16, 2018 6:09 am Post subject: |
|
|
Apprentice
Joined: 29 Sep 2017 Posts: 45
|
@Vitor but is there a possibility for me, as client, to fulfil the requirement (using unique CCDTs on one client app). How can I circumvent this Environment variable problem for CCDT?
"I still don't see why you can't have 1 specific connection for each possible queue manager in a single CCDT, with the application still connecting to each queue manager as described above. "
Lets suppose we have one CCDT, how can we make several excplicit connections? |
|
Back to top |
|
 |
Vitor |
Posted: Mon Jul 16, 2018 6:20 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
dudetom wrote: |
@Vitor but is there a possibility for me, as client, to fulfil the requirement (using unique CCDTs on one client app). How can I circumvent this Environment variable problem for CCDT? |
I don't see how. If this is all running as a single process, then there's only 1 runtime environment into which you can export an environment variable. That's nothing to do with MQ or CCDT but the way the OS isolates applications.
dudetom wrote: |
Lets suppose we have one CCDT, how can we make several excplicit connections? |
The CCDT is nothing more than a list of connection details about where the client can find a given queue manager. We've already established that the onus is on the application to connect to each of the possible queue managers. It's worth pointing out here that the CCDT never load balances connections but will always connect to the first responding queue manager in the list.
So rather than having application code that connects to a generic queue manager and relies on the fact that there's only 1 queue manager in the CCDT, but it's a different CCDT for each request, connect to each queue manager by name with all the connection information in a single CCDT.
You may say that this now means the application has to know the names of each possible target, which is true. But if you could use different environment variables to use 1 CCDT for each connection, you'd still need to know how many CCDTs where in use. So in your solution you need to know how many target queue managers there are, in mine you need to know how many and their names.
So not that different. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
dudetom |
Posted: Mon Jul 16, 2018 6:34 am Post subject: |
|
|
Apprentice
Joined: 29 Sep 2017 Posts: 45
|
Vitor Can you also show me how I can make these different connections using 1 CCDT? What if the QM name is the same?
And if not possible, The only way for solution is to make separate applications (services) so the environment variables has its own scope on the different applications so the correct CCDT will always be used then. |
|
Back to top |
|
 |
dudetom |
Posted: Mon Jul 16, 2018 6:41 am Post subject: |
|
|
Apprentice
Joined: 29 Sep 2017 Posts: 45
|
By the way, in my opinion it's so weird that this simple functionality is not available... Why do we have to make us dependent on some environment variables while we have our fully functioning application. Those two variables, MQCHLLIB and MQCHLTAB should be adjustable in closer lifespans also, instead of the Process level or Global level... |
|
Back to top |
|
 |
Vitor |
Posted: Mon Jul 16, 2018 6:42 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
dudetom wrote: |
Vitor Can you also show me how I can make these different connections using 1 CCDT? What if the QM name is the same? |
If your client has multiple queue managers with the same name then they're going against best practice into worst practice. This is going to bite them in the contact admin one day and has already bitten you. The MQ software assumes queue managers are unique within an estate, and this explains why you need one CCDT per queue manager - it's the only way to tell them apart because MQ will assume they're all the same one.
dudetom wrote: |
The only way for solution is to make separate applications (services) so the environment variables has its own scope on the different applications so the correct CCDT will always be used then. |
Yep, you're going to need each application in it's own command shell so you can export individual copies of the CCDT into them. This will of course multiply your administrative and maintenance effort by a factor of however many queue managers your client has, and will require another application to be spun up every time your client scales. Which they'll have to do more frequently than usual because they can't use an MQ cluster to share workload. AN MQ cluster will absolutely not work if all the member queue managers have the same name.
See above re: worst practice. Your client has done a contact admin on you. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
dudetom |
Posted: Mon Jul 16, 2018 8:28 am Post subject: |
|
|
Apprentice
Joined: 29 Sep 2017 Posts: 45
|
To clarify, we are the client connecting to the their qm server.
We have little ibm mq knowledge... |
|
Back to top |
|
 |
Vitor |
Posted: Mon Jul 16, 2018 8:53 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
dudetom wrote: |
To clarify, we are the client connecting to the their qm server. |
I guessed that from the use of the CCDT  _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Mon Jul 16, 2018 6:47 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
The following link shows how to have multiple queue managers referenced in one CCDT. And optionally makes reference to how the CCDT can load balance the connections for you if you desire.
https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_8.0.0/com.ibm.mq.dev.doc/q027490_.htm
If you have multiple QMs with the same name on your network, how you can make it work with a single CCDT so you can control which one you connect to I do not know. Multiple QMs on the same network with the same name is bad news. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
fjb_saper |
Posted: Mon Jul 16, 2018 8:27 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
You may have to do as requested if the channel for the client connection is the same for each queue manager.
Just pass the CCDTURL in the hashtable when creating the connection. This way you can have a different CCDT URL per hashtable / connection.
Have fun  _________________ MQ & Broker admin |
|
Back to top |
|
 |
dudetom |
Posted: Tue Jul 17, 2018 10:28 pm Post subject: |
|
|
Apprentice
Joined: 29 Sep 2017 Posts: 45
|
@fjb_saper I tried setting the CCDTURL
_cf.SetStringProperty(XMSC.WMQ_CCDTURL, @"file://C:\" + ccdt);
But it has no effect, in the event viewer I always see it's searching for a file: 'C:\ProgramData\IBM\MQ\AMQCLCHL.TAB'. Even my filename is something else. I can conclude that the property I've set has no effect...
Is it because I'm using an older version of IBM MQ? I'm using 8.0.0.5. |
|
Back to top |
|
 |
dudetom |
Posted: Wed Jul 18, 2018 1:43 am Post subject: |
|
|
Apprentice
Joined: 29 Sep 2017 Posts: 45
|
I try same settings, once with client mode and once with unmanaged mode.
Event viewer gives different output related to CCDT. In unmanaged it looks for the default location.
- Client mode event viewer event: [url]pasted.co/27db600f[/url] (CCDT does not exist but it looks in the right directory which is good)
- Unmanaged mode event viewer event: [url]pasted.co/d5979a2c[/url] |
|
Back to top |
|
 |
|