Author |
Message
|
vsathyan |
Posted: Tue Aug 12, 2014 4:07 am Post subject: Alias to cluster QLOCAL - msg delivery based on CLWLRANK |
|
|
Centurion
Joined: 10 Mar 2014 Posts: 121
|
Here is the MQ setup
QMGR1 - DEFINE QALIAS(QA.TEST) TARGET(QL.TEST)
QMGR2 - DEFINE QL(QL.TEST) CLUSTER(CL) DEFBIND(NOTFIXED) CLWLRANK(9)
QMGR3 - DEFINE QL(QL.TEST) CLUSTER(CL) DEFBIND(NOTFIXED) CLWLRANK(
All the three queue managers - QMGR1, QMGR2 and QMGR3 are partial repository members of the same cluster - CL.
**** Alias queues are not shared in the cluster ****
Here is the test case. Application connects to the alias queue - QA.TEST and puts the messages.
a. When both the cluster queue instances are available, messages reach only the cluster local queue with higher rank (expected).
b. When put is disabled on the local queue with higher cluster rank, the messages are not delivered to the other queue which is
available in the cluster. (Not expected. Messages should be delivered to the other cluster queue instance which is available with a lower rank CLWLRANK( )
When the same scenario is tested by opening the cluster local queue directly,
a. When both the cluster queue instances are available, messages reach only the cluster local queue with higher rank (expected).
b. When put is disabled on the local queue with higher cluster rank, the messages now reach the second instance of the queue in the cluster (expected)
From what I understand is, the message load distribution happens only if the application directly opens a cluster queue with DEFBIND(NOTFIXED).
(Whether alias or local - it must be in a member of the cluster and DEFBIND attribute set to NOTFIXED).
I do not want to share the alias queue in the cluster, as we are separating out putting and getting applications by using alias queues.
For example -
QA.TEST - alias queue will be created on all queue managers - QMGR1, QMGR2 and QMGR3.
QA.TEST on QMGR1 - app1 put, get disabled.
QA.TEST on QMGR2, QMGR3 - app2 get, put disabled.
We do not want the application to open the cluster local queues directly (to put or get messages). We have to use alias queues.
Issue -
For the reason that initially the alias had bound to the cluster local queue with higher rank, the messages are not being delivered to the second local queue instance in the cluster.
If the queue manager QMGR2 goes down, the second instance is available in QMGR3, but the messages are not being delivered in the queue in QMGR3 and are getting stuck in the SYSTEM.CLUSTER.TRANSMIT.QUEUE in QMGR2.
Any suggestions or inputs to fix this - so that the messages are delivered to the next available instance of the cluster local queue with higher clwlrank the via the alias queue. |
|
Back to top |
|
 |
JosephGramig |
Posted: Tue Aug 12, 2014 4:44 am Post subject: |
|
|
 Grand Master
Joined: 09 Feb 2006 Posts: 1244 Location: Gold Coast of Florida, USA
|
The cluster attributes of the QALIAS override the target's settings. The defaults would be DEFBIND(OPEN) CLWLRANK(0). |
|
Back to top |
|
 |
vsathyan |
Posted: Tue Aug 12, 2014 5:01 am Post subject: |
|
|
Centurion
Joined: 10 Mar 2014 Posts: 121
|
As mentioned in my initial post, we do not want the alias queues to be shared in the cluster and it is not currently shared too.
So, is there any way where i can deliver messages to any available cluster queue instance using an alias queue (or not)?  |
|
Back to top |
|
 |
tczielke |
Posted: Tue Aug 12, 2014 5:40 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010 Posts: 941 Location: Illinois, USA
|
Quote: |
b. When put is disabled on the local queue with higher cluster rank, the messages are not delivered to the other queue which is
available in the cluster. (Not expected. Messages should be delivered to the other cluster queue instance which is available with a lower rank CLWLRANK |
This is not how CLWLRANK works. The queue with the higher CLWLRANK forces messages to be delivered only to that queue, and to ignore queues with a lower rank. That is the purpose of CLWLRANK. To tell the cluster WLM that messages have to be delivered to the queue with the higher rank. |
|
Back to top |
|
 |
mqjeff |
Posted: Tue Aug 12, 2014 5:51 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
tczielke wrote: |
Quote: |
b. When put is disabled on the local queue with higher cluster rank, the messages are not delivered to the other queue which is
available in the cluster. (Not expected. Messages should be delivered to the other cluster queue instance which is available with a lower rank CLWLRANK |
This is not how CLWLRANK works. The queue with the higher CLWLRANK forces messages to be delivered only to that queue, and to ignore queues with a lower rank. That is the purpose of CLWLRANK. To tell the cluster WLM that messages have to be delivered to the queue with the higher rank. |
Assuming that the sending application is has not chosen to Bind on Open. |
|
Back to top |
|
 |
vsathyan |
Posted: Fri Aug 22, 2014 8:05 am Post subject: |
|
|
Centurion
Joined: 10 Mar 2014 Posts: 121
|
Quote: |
b. When put is disabled on the local queue with higher cluster rank, the messages are not delivered to the other queue which is
available in the cluster. (Not expected. Messages should be delivered to the other cluster queue instance which is available with a lower rank CLWLRANK
|
Even if the queue manager where the higher priority cluster queue goes down and the queue manager is not available also - the messages from the alias queue is not reaching the other cluster queue, with lesser CLWLRANK in the second queue manager.
Any thoughts? |
|
Back to top |
|
 |
tczielke |
Posted: Fri Aug 22, 2014 8:11 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010 Posts: 941 Location: Illinois, USA
|
|
Back to top |
|
 |
mqjeff |
Posted: Fri Aug 22, 2014 8:12 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
Also.
You really really really really have to MAKE SURE the application isn't specifying BIND ON OPEN. |
|
Back to top |
|
 |
|