| Author |
Message
|
| orman |
 Posted: Wed Jan 28, 2015 8:53 pm Post subject: Dealing AA with MQ clients java applications |
 |
|
Apprentice
Joined: 08 Aug 2013
Posts: 40
|
Hello everyone,
I asked this question first on the WebSphere MQ Java forum, I decided to move it the this one.
I am a broker developer (for 5 years), and recently we want to migrate our environment to be AA.
We have some MQ clients java applications that works with out QMs.
Our environment is like:
QM1 multi-instance (2 hosts)
QM2 multi-instance (2 hosts)
What means -
1. Load balancing between 2 QM (QM1/QM2)
2. Dealing with scenario of failure - HA (standby goes to active)
So, I thought about ways to figure out this case
1 - MQ cluster between the 2 QMs
2 - make my MQ client applications use CCDT file (*.TAB) to reconnect when MQ connection fail
I was looking on the web and use this one -
http://www-01.ibm.com/support/docview.wss?uid=swg27020848
What about using 2 QM's of the broker to be clustered together
* Scenario 5 - Queue Manager Group: ' ' (1 blank character) - helps for AA (2 different instances running parallel)
* Scenario 7 - Multi-Instance Queue Manager (hot backup for any instance)
MQ client application will connect to an active QM and the message will LB between the active instance.
I tested it and it works well but, I don't really like the CCDT configuration.
It is not that readable and the file is binary (i know i can use MQSC command).
I would like to have a connection configuration in clear-text file that is editable and readable.
What do you think about that ?
*Another solution is to use DNS LB which LB when using put (after disconnect) and deal in case of failure
**Another problem that I didn't figure yet is MQGet -
when application is listening to queue - should it listen to all my AA QMs or just to one of it - means the QMs wont act as AA when send messages to clients.
What is your opinion ?
Additional question,
DataPower as another MQ client does not using the CCDT file. So, how can I use it to works well?
I read some correspondences about it and as I understand for now there is no support with CCDT so the best solution is
1. For sending (MQPut) - using MQ cluster load balancing
2. For receiving (MQGet) - each DP as to listen to all the active QMs
What do you say about it ?
Thank, Or.  |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Wed Jan 28, 2015 9:12 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
So did you test each scenario? What was the result? What has you puzzled? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Jan 29, 2015 12:59 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Support pac MO72 allows maintenance of CCDT in source form
http://www-01.ibm.com/support/docview.wss?uid=swg24007769
You can maintain your CCDTs in source form and just regenerate the binary file after any changes with MO72 (you can use any platform to do this).
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Jan 29, 2015 4:57 am Post subject: Re: Dealing AA with MQ clients java applications |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| orman wrote: |
| ... we want to migrate our environment to be AA. |
AA?
_________________
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 |
|
|
| Vitor |
| Posted: Thu Jan 29, 2015 6:05 am Post subject: Re: Dealing AA with MQ clients java applications |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bruce2359 wrote: |
| orman wrote: |
| ... we want to migrate our environment to be AA. |
AA? |
Active / Active?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Jan 29, 2015 6:51 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
There are 12 steps for the AA program... 
Or it could be credit rating style AAA, B+ etc
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Jan 29, 2015 7:52 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Always Available? As opposed to Highly Available?
In general to achieve this, you need to have each client connected to more than one queue manager (not an MI pair, two separate queue managers which could both be ha pairs).
You then need to code for how this affects your message patterns. |
|
| Back to top |
|
|
| orman |
| Posted: Thu Jan 29, 2015 11:44 pm Post subject: |
|
|
Apprentice
Joined: 08 Aug 2013
Posts: 40
|
Hey
First of all thanks for the answers
| fjb_saper wrote: |
So did you test each scenario? What was the result? What has you puzzled?
|
Well, I test using CCDT file on java example program, as i said it worked but i think it is not good enough because this it is a binary file.
DataPower - does not support this one, so it as to make:
1. For sending (MQPut) - using MQ cluster load balancing
2. For receiving (MQGet) - each DP as to listen to all the active QMs
| zpat wrote: |
| You can maintain your CCDTs in source form and just regenerate the binary file after any changes with MO72 (you can use any platform to do this). |
Ok. I read ths MQSC help again, maybe it could be useful if we will decided to use this one.
By the way, as I know, MQ api does not have option for ConnectionName beside - JMS api.
(Just when using *.TAB file)
| Vitor wrote: |
| bruce2359 wrote: |
| orman wrote: |
| ... we want to migrate our environment to be AA. |
AA? |
Active / Active? |
AA - yeah, I meant Active-Active (with want to make our environment scalability)
| mqjeff wrote: |
Always Available? As opposed to Highly Available?
In general to achieve this, you need to have each client connected to more than one queue manager (not an MI pair, two separate queue managers which could both be ha pairs).
You then need to code for how this affects your message patterns. |
Yeah, you right. We will think about it. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Fri Jan 30, 2015 12:09 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| Quote: |
Well, I test using CCDT file on java example program, as i said it worked but i think it is not good enough because this it is a binary file.
|
would you care to explain why this isn't good enough?
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jan 30, 2015 5:06 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| smdavies99 wrote: |
| Quote: |
Well, I test using CCDT file on java example program, as i said it worked but i think it is not good enough because this it is a binary file.
|
would you care to explain why this isn't good enough? |
It's not like it's not generated from controllable source.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Jan 30, 2015 5:38 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
In the C API for messaging, you can choose to connect to a queue manager using two forms - an MQCONN or an MQCONNX call. The MQCONN call only takes a queue manager name - or various kinds of standins for queue manager names (including none).
The MQCONNX call lets you specify every last little detail of the connection infromation you want, including in v8 the username and password you want to authenticate with.
In the Java API, you have instead an MQQueueManager object, that represents the connection. You can then set a large number of properties to control how to create the connection.
The JMS API follows the standards of JMS, and limits the number of configuration properties you can specify in code, instead relying on the JMS administrator to configure the JMS Connection Factory and Destination objects to specify the needed properties. With MQ JMS, using a CCDT gives you a good way to control a larger number of connection properties than the JMS administration properties give you.
As mentioned, the CCDT is regenerated from definitions made on a queue manager. In MQv8, the MQ client has the ability to also create a CCDT without a qmgr (if I recall correctly). You can also just write a script that creates a temporary queue manager, applies a bunch of MQSC, copies the resulting CCDT and then deletes the qmgr. Or just uses an existing qmgr set aside for that purpose. |
|
| Back to top |
|
|
| orman |
| Posted: Mon Feb 02, 2015 9:04 am Post subject: |
|
|
Apprentice
Joined: 08 Aug 2013
Posts: 40
|
Hey
Thanks for answers, I still have to make some tests on my environment
If I will have another dilemmas I will raise them up
Have a good day  |
|
| Back to top |
|
|
|
|
