Author |
Message
|
epic |
Posted: Thu Sep 14, 2006 8:50 am Post subject: QALIAS Put goes to wrong clustered QLOCAL ignoring CLWLPRTY |
|
|
Newbie
Joined: 14 Sep 2006 Posts: 5
|
I have a localq Q1 defined on qmgr QM1 in cluster C1 with CLWLPRTY(2)
I also have Q1 defined on qmgr QM2 in cluster C1 with CLWLPRTY(1)
The intention is that Q1 on QM2 is a backup for Q1 on QM1 and will only be used if QM1 is unavailable. This works fine for amqsputc to Q1.
I also have a QALIAS QA1 defined on both qmgrs in the same cluster specifying TARGQ(Q1). When I do an amqsputc to QA1 via QM1 the message always ends up in Q1 on QM2. Similary, if I connect to QM2 and do the same the messages ends up on QM1.
How can I get MQPuts to the Alias to honor the Cluster Workload Priority and prefer QM1 over QM2 in the same way that MQPuts to the queue directly work?
This is MQ V.6 on Linux
--
Andrew |
|
Back to top |
|
 |
HubertKleinmanns |
Posted: Thu Sep 14, 2006 9:46 am Post subject: Re: QALIAS Put goes to wrong clustered QLOCAL ignoring CLWLP |
|
|
 Shaman
Joined: 24 Feb 2004 Posts: 732 Location: Germany
|
epic wrote: |
... I also have a QALIAS QA1 defined on both qmgrs in the same cluster specifying TARGQ(Q1). When I do an amqsputc to QA1 via QM1 the message always ends up in Q1 on QM2. Similary, if I connect to QM2 and do the same the messages ends up on QM1.
... |
I would expect it the other way round. When you use defaults, local queues are always preferred. You should post the definitions of your queues and channel. _________________ Regards
Hubert |
|
Back to top |
|
 |
fjb_saper |
Posted: Thu Sep 14, 2006 2:44 pm Post subject: Re: QALIAS Put goes to wrong clustered QLOCAL ignoring CLWLP |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
HubertKleinmanns wrote: |
epic wrote: |
... I also have a QALIAS QA1 defined on both qmgrs in the same cluster specifying TARGQ(Q1). When I do an amqsputc to QA1 via QM1 the message always ends up in Q1 on QM2. Similary, if I connect to QM2 and do the same the messages ends up on QM1.
... |
I would expect it the other way round. When you use defaults, local queues are always preferred. You should post the definitions of your queues and channel. |
In V6 there is an additional parameter that needs to be set (default behavior is like in V5).
However if you want one of the qmgr to be "like" a failover you need to change the priorities:
set CLWLPRTY(9) on your primary and set CLWLPRTY(0) on your failover. As long as the primary is available the failover will see no traffic.
What you had was a 1/3 2/3 distribution
Enjoy  _________________ MQ & Broker admin |
|
Back to top |
|
 |
epic |
Posted: Fri Sep 15, 2006 2:08 am Post subject: |
|
|
Newbie
Joined: 14 Sep 2006 Posts: 5
|
Ok these are the definitions but with the CLWLPRTY set to 9 for the primary and 0 for the failover standby as advised by fjb_saper. The behavior is still the same i.e. an MQPut to Q1 goes to QM1 but a MQPut to QA1 goes to Q1 on QM2.
QM1 (Full Repos)
ALTER QMGR REPOS(C1) CLWLUSEQ(ANY)
DEFINE QALIAS ('QA1') TARGQ('Q1') CLUSTER('C1') CLWLPRTY(9) REPLACE
DEFINE QLOCAL ('Q1') CLWLUSEQ(QMGR) CLUSTER('C1') CLWLPRTY(9) REPLACE
DEFINE CHANNEL ('TO.QM1') CHLTYPE(CLUSRCVR) TRPTYPE(TCP) CLUSTER('C1') CONNAME('localhost(1414)') CLWLPRTY(9) REPLACE
DEFINE LISTENER ('L1') TRPTYPE(TCP) IPADDR(' ') PORT(1414) CONTROL(QMGR) REPLACE
QM2 (Partial Repos)
ALTER QMGR CLWLUSEQ(ANY)
DEFINE QALIAS ('QA1') TARGQ('Q1') CLUSTER('C1') CLWLPRTY(0) REPLACE
DEFINE QLOCAL ('Q1') CLWLUSEQ(QMGR) CLUSTER('C1') CLWLPRTY(0) REPLACE
DEFINE CHANNEL ('TO.QM1') CHLTYPE(CLUSSDR) TRPTYPE(TCP) CLUSTER('C1') CONNAME('localhost(1414)') CLWLPRTY(0) REPLACE
DEFINE CHANNEL ('TO.QM2') CHLTYPE(CLUSRCVR) TRPTYPE(TCP) CLUSTER('C1') CONNAME('localhost(1415)') CLWLPRTY(0) REPLACE
DEFINE LISTENER ('L2') TRPTYPE(TCP) IPADDR(' ') PORT(1415) CONTROL(QMGR) REPLACE
--
Andrew |
|
Back to top |
|
 |
epic |
Posted: Fri Sep 15, 2006 8:46 am Post subject: |
|
|
Newbie
Joined: 14 Sep 2006 Posts: 5
|
I've now tried to reproduce the problem on MQ on Windows with the same definitions but on Windows it all works as expected. Incidentally it's MQ V.6.0.1.1 on both the failing Linux environment and on Win XP.
--
Andrew |
|
Back to top |
|
 |
fjb_saper |
Posted: Fri Sep 15, 2006 2:55 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
No problems with it on AIX. I just set the qc cluster priority, nothing with the channel.
Enjoy  _________________ MQ & Broker admin |
|
Back to top |
|
 |
Ivans |
Posted: Sat Sep 16, 2006 11:22 am Post subject: |
|
|
Apprentice
Joined: 03 Jan 2006 Posts: 48 Location: Hursley
|
Andrew,
I've just been having a play in my Windows sandbox and think I've managed to re-create the problem. I've narrowed it down to using alias queues that resolve to cluster queues and using bind-on-open. I suggest you raise a PMR and feel free to add my name to it (Ian Vanstone) in this instance, as I can pass on what I know to the service team.
Cheers,
Ian |
|
Back to top |
|
 |
jefflowrey |
Posted: Sat Sep 16, 2006 3:34 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
Well, I would expect that Bind-On-Open would trump CLWLPRTY. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
fjb_saper |
Posted: Sat Sep 16, 2006 3:41 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
jefflowrey wrote: |
Well, I would expect that Bind-On-Open would trump CLWLPRTY. |
My Alias queues have all bind not fixed. How ever even with bind on open I would expect it to use the clwlprty. The only reason for it to go to the "failover" (CLWLPRTY=0) and stay there would have been for the primary not to be available on the first access to the queue...
Bind on open should only trump cluster workload priority after the first resolution has been made. I could see it go the wrong way however if he had his failover workload priority set to 1 instead of 0. Then what he sees could be expected behavior...
Enjoy  _________________ MQ & Broker admin |
|
Back to top |
|
 |
jefflowrey |
Posted: Sat Sep 16, 2006 4:44 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
fjb_saper wrote: |
Bind on open should only trump cluster workload priority after the first resolution has been made. |
Yes. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
HubertKleinmanns |
Posted: Tue Sep 19, 2006 8:42 am Post subject: |
|
|
 Shaman
Joined: 24 Feb 2004 Posts: 732 Location: Germany
|
fjb_saper wrote: |
jefflowrey wrote: |
Well, I would expect that Bind-On-Open would trump CLWLPRTY. |
My Alias queues have all bind not fixed. How ever even with bind on open I would expect it to use the clwlprty. The only reason for it to go to the "failover" (CLWLPRTY=0) and stay there would have been for the primary not to be available on the first access to the queue...
Bind on open should only trump cluster workload priority after the first resolution has been made. I could see it go the wrong way however if he had his failover workload priority set to 1 instead of 0. Then what he sees could be expected behavior...
Enjoy  |
fjb_saper,
an alias q with DEFBIND(OPEN) does only resolve to local defined queues and not to cluster queues somewhere else. This is documented in the guide MQQueue Manager Clusters in the chapter Using aliases and remote-queue definitions with clusters:
Quote: |
When you open a queue you need to set DEFBIND to either (NOTFIXED) or (QDEF) because if it is left as the default (OPEN) the queue manager will resolve the alias definition to the bridge queue manager that hosts it, and the bridge will not forward the message on. |
_________________ Regards
Hubert |
|
Back to top |
|
 |
tleichen |
Posted: Tue Sep 19, 2006 10:14 am Post subject: |
|
|
Yatiri
Joined: 11 Apr 2005 Posts: 663 Location: Center of the USA
|
HubertKleinmanns wrote: |
Quote: |
When you open a queue you need to set DEFBIND to either (NOTFIXED) or (QDEF) because if it is left as the default (OPEN) the queue manager will resolve the alias definition to the bridge queue manager that hosts it, and the bridge will not forward the message on. |
|
So, we can just call this a "feature"?  _________________ IBM Certified MQSeries Specialist
IBM Certified MQSeries Developer |
|
Back to top |
|
 |
Ivans |
Posted: Tue Sep 19, 2006 11:24 am Post subject: |
|
|
Apprentice
Joined: 03 Jan 2006 Posts: 48 Location: Hursley
|
Hubert,
The advice to you quoted 'to set DEFBIND to either (NOTFIXED) or (QDEF)' is specific to passing messages through overlapping clusters, as in the example.
If bind on open is used, the bridge (or gateway) queue manager cannot pass the message on to the target queue manager because the source queue manager has bound the message to the gateway queue manager at MQOPEN time.
It is perfectly acceptable for an alias queue to resolve to a (remote) cluster queue. This is often used to restrict access to cluster queues, by securing the local alias queue and only making the alias queue name (rather than the cluster queue name) available to applications.
Cheers,
Ian |
|
Back to top |
|
 |
HubertKleinmanns |
Posted: Tue Sep 19, 2006 10:33 pm Post subject: |
|
|
 Shaman
Joined: 24 Feb 2004 Posts: 732 Location: Germany
|
tleichen wrote: |
...
So, we can just call this a "feature"?  |
tleichen,
as Ian describes you may wish to restrict access to cluster queues and therefore: Yes it is a feature.
Ian,
you are right, but it is very important, to know about this behaviour, to understand, where messages go. I think the situation described in this thread should be able, to put messages to cluster queues. _________________ Regards
Hubert |
|
Back to top |
|
 |
Ivans |
Posted: Tue Sep 19, 2006 11:41 pm Post subject: |
|
|
Apprentice
Joined: 03 Jan 2006 Posts: 48 Location: Hursley
|
Using alias queues to resolve to cluster queues (whether local or remote and whether using bind not fixed or bind on open) is a feature.
The situation Andrew describes is most likely a bug.
Cheers,
Ian |
|
Back to top |
|
 |
|