Author |
Message
|
LJM |
Posted: Thu Jul 11, 2019 7:37 am Post subject: CCDT round robin and GET |
|
|
Novice
Joined: 05 Jul 2018 Posts: 22
|
Hi ALl,
just a quickie
i define a CCDT for my client to use
eg
DEFINE CHANNEL(QM1.SVRCONN) CHLTYPE(CLNTCONN) CONNAME('qmgr1(1701)') AFFINITY(NONE) CLNTWGHT(50) QMNAME(QM1)
DEFINE CHANNEL(QM2.SVRCONN) CHLTYPE(CLNTCONN) CONNAME('qmgr2(1701)') AFFINITY(NONE) CLNTWGHT(50) QMNAME(QM2)
this will round robin my mq ( java ) clients when PUT to Q1 between QM1 and QM2 evenly
however
will this also round robin my client when GET from Q2 between QM1 and QM2 ?
i cant test this yet, just want a theoretical answer to feed back to dev team
Thanks
Loz |
|
Back to top |
|
 |
exerk |
Posted: Thu Jul 11, 2019 8:16 am Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
Presumably you will 'round-robin' the client applications because Client 1 - 5 will specify one queue manager, and Client 6 - 10 will specify the other?
Do the client applications PUT only and GET only, or can they PUT AND GET?
Do you want to automatically load-balance the client applications? If so, investigate the automatic load-balancing of JMS MQ Clients introduced with v9.1.3. _________________ It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
Back to top |
|
 |
LJM |
Posted: Thu Jul 11, 2019 8:23 am Post subject: |
|
|
Novice
Joined: 05 Jul 2018 Posts: 22
|
Hi,
situation is two qmrs, QM1 and QM2 with same locally defined clsuter queue Q,
i have upstream QMGR PUT to cluster in a RR DEFBIND(NOTFIXED) to distribute load to Q@QM1 and Q@QM2
i have some java then GET only from Q@QM1 and same java on" another box" GET from Q@QM2
i want to add a little redundacny so my java GET from Q@QM1 / Q@QM2 round robin - was thinking via CCDT - just in case java box fails,
im on WMQ8 here ( i know ! ) |
|
Back to top |
|
 |
exerk |
Posted: Thu Jul 11, 2019 8:54 am Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
Have two threads/instances from each 'java box', one thread/instance connecting to QM1 and the other to QM2. If one 'java box' fails, there will be at least one thread/instance servicing each queue in each queue manager. _________________ It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
Back to top |
|
 |
bruce2359 |
Posted: Thu Jul 11, 2019 8:56 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
LJM wrote: |
i have upstream QMGR PUT to cluster in a RR DEFBIND(NOTFIXED) to distribute load to Q@QM1 and Q@QM2
|
Does the app specify BIND option to explicitly override the DEFBIND? _________________ 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 |
|
 |
hughson |
Posted: Thu Jul 11, 2019 8:42 pm Post subject: Re: CCDT round robin and GET |
|
|
 Padawan
Joined: 09 May 2013 Posts: 1959 Location: Bay of Plenty, New Zealand
|
LJM wrote: |
i define a CCDT for my client to use
DEFINE CHANNEL(QM1.SVRCONN) CHLTYPE(CLNTCONN) CONNAME('qmgr1(1701)') AFFINITY(NONE) CLNTWGHT(50) QMNAME(QM1)
DEFINE CHANNEL(QM2.SVRCONN) CHLTYPE(CLNTCONN) CONNAME('qmgr2(1701)') AFFINITY(NONE) CLNTWGHT(50) QMNAME(QM2)
this will round robin my mq ( java ) clients when PUT to Q1 between QM1 and QM2 evenly |
A CCDT does not have an effect on MQPUT. The CCDT has an effect on MQCONN. If your CCDT is round-robin-ing your MQPUTs, you must be doing an MQCONN for every MQPUT which is ill-advised.
You mention that you also have clustering with BIND(NOTFIXED). It will be this technology that is round-robin-ing your MQPUTs. The CCDT is just providing connectivity.
Your CCDT as above is not even providing connectivity fail-over/redundancy, since both QMNAME fields have different values. If you created a group of CCDT entries all with the same QMNAME (a group name you invent), then this could provide some connectivity fail-over if one member of the group wasn't available.
Cheers,
Morag _________________ Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
Back to top |
|
 |
LJM |
Posted: Fri Jul 12, 2019 3:48 am Post subject: |
|
|
Novice
Joined: 05 Jul 2018 Posts: 22
|
Hi Morag, yes a typo in my thread, i was using your example for CCDT from your MQGEM post #8
..........
I think im just asking the wrong question,
can i use CCDT on my clients to round robin GETS from a Q@QM1 and Q@QM2
eg get from 1st , then get from 2nd, then get from 1st then get from 2nd.
by way of connecting to one then connecting to the other in the list
Im purely from an comms / infra view, ill let the dev worry about the code of the MQCONN, and any WITH WAITS and all that jazz. |
|
Back to top |
|
 |
Vitor |
Posted: Fri Jul 12, 2019 4:17 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
LJM wrote: |
HI think im just asking the wrong question, |
You're also thinking about this the wrong way.
LJM wrote: |
can i use CCDT on my clients to round robin GETS from a Q@QM1 and Q@QM2
eg get from 1st , then get from 2nd, then get from 1st then get from 2nd.
by way of connecting to one then connecting to the other in the list |
Connecting is a computationally expensive operation. The application should connect to the queue managers, then continue to use those existing connections for the get operations.
LJM wrote: |
Im purely from an comms / infra view, ill let the dev worry about the code of the MQCONN, and any WITH WAITS and all that jazz. |
And if you tell the devs / let the devs "connect to one and then the other", not only will they complain about poor MQ performance but all the bandwidth in your infrastructure will be sucked up.
A better way would be as my worthy associate alluded to. Define one CCDT that has queue managers in the order QM1 / QM2, and another in the order QM2 / QM1 but both have an attribute of QMGRNAME(YOURQMGR). Give half the application one CCDT, the other half the other, and tell everybody to connect to a queue manager called YOURQMGR.
This will distribute the connections and if one queue manager fails, the reconnect will automatically switch over to the surviving queue manager. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
exerk |
Posted: Fri Jul 12, 2019 4:18 am Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
LJM wrote: |
...can i use CCDT on my clients to round robin GETS from a Q@QM1 and Q@QM2
eg get from 1st , then get from 2nd, then get from 1st then get from 2nd.
by way of connecting to one then connecting to the other in the list... |
You can but it's horrifically inefficient and resource-intensive - the major hit is on the conn/disconn. My advice is - DON'T!
And I suspect others will back me on that...
...and, as if by magic  _________________ It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
Back to top |
|
 |
LJM |
Posted: Fri Jul 12, 2019 4:20 am Post subject: |
|
|
Novice
Joined: 05 Jul 2018 Posts: 22
|
Vitor wrote: |
A better way would be as my worthy associate alluded to. Define one CCDT that has queue managers in the order QM1 / QM2, and another in the order QM2 / QM1 but both have an attribute of QMGRNAME(YOURQMGR). Give half the application one CCDT, the other half the other, and tell everybody to connect to a queue manager called YOURQMGR.
This will distribute the connections and if one queue manager fails, the reconnect will automatically switch over to the surviving queue manager. |
Thanks - i now ( finaly ) understand |
|
Back to top |
|
 |
LJM |
Posted: Fri Jul 12, 2019 4:21 am Post subject: |
|
|
Novice
Joined: 05 Jul 2018 Posts: 22
|
exerk wrote: |
Have two threads/instances from each 'java box', one thread/instance connecting to QM1 and the other to QM2. If one 'java box' fails, there will be at least one thread/instance servicing each queue in each queue manager. |
thanks agian |
|
Back to top |
|
 |
Vitor |
Posted: Fri Jul 12, 2019 4:38 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
exerk wrote: |
...and, as if by magic  |
Bibberdy.....bobberdy......boo! _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
exerk |
Posted: Fri Jul 12, 2019 4:40 am Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
Vitor wrote: |
exerk wrote: |
...and, as if by magic  |
Bibberdy.....bobberdy......boo! |
No wizardy emoticon unfortunately, so I shall name you Zardoz  _________________ It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
Back to top |
|
 |
Vitor |
Posted: Fri Jul 12, 2019 4:47 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
exerk wrote: |
Vitor wrote: |
exerk wrote: |
...and, as if by magic  |
Bibberdy.....bobberdy......boo! |
No wizardy emoticon unfortunately, so I shall name you Zardoz  |
Ok, I'm good with the flying head but if Sean Connery turns up bare chested sporting leather trousers I'm outta here!!!! _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
exerk |
Posted: Fri Jul 12, 2019 5:04 am Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
Vitor wrote: |
exerk wrote: |
Vitor wrote: |
exerk wrote: |
...and, as if by magic  |
Bibberdy.....bobberdy......boo! |
No wizardy emoticon unfortunately, so I shall name you Zardoz  |
Ok, I'm good with the flying head but if Sean Connery turns up bare chested sporting leather trousers I'm outta here!!!! |
Or Admiral Baldrick... _________________ It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
Back to top |
|
 |
|