ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » Clustering » QALIAS Put goes to wrong clustered QLOCAL ignoring CLWLPRTY

Post new topic  Reply to topic Goto page 1, 2  Next
 QALIAS Put goes to wrong clustered QLOCAL ignoring CLWLPRTY « View previous topic :: View next topic » 
Author Message
epic
PostPosted: Thu Sep 14, 2006 8:50 am    Post subject: QALIAS Put goes to wrong clustered QLOCAL ignoring CLWLPRTY Reply with quote

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
View user's profile Send private message
HubertKleinmanns
PostPosted: Thu Sep 14, 2006 9:46 am    Post subject: Re: QALIAS Put goes to wrong clustered QLOCAL ignoring CLWLP Reply with quote

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
View user's profile Send private message Visit poster's website
fjb_saper
PostPosted: Thu Sep 14, 2006 2:44 pm    Post subject: Re: QALIAS Put goes to wrong clustered QLOCAL ignoring CLWLP Reply with quote

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
View user's profile Send private message Send e-mail
epic
PostPosted: Fri Sep 15, 2006 2:08 am    Post subject: Reply with quote

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
View user's profile Send private message
epic
PostPosted: Fri Sep 15, 2006 8:46 am    Post subject: Reply with quote

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
View user's profile Send private message
fjb_saper
PostPosted: Fri Sep 15, 2006 2:55 pm    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
Ivans
PostPosted: Sat Sep 16, 2006 11:22 am    Post subject: Reply with quote

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
View user's profile Send private message
jefflowrey
PostPosted: Sat Sep 16, 2006 3:34 pm    Post subject: Reply with quote

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
View user's profile Send private message
fjb_saper
PostPosted: Sat Sep 16, 2006 3:41 pm    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
jefflowrey
PostPosted: Sat Sep 16, 2006 4:44 pm    Post subject: Reply with quote

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
View user's profile Send private message
HubertKleinmanns
PostPosted: Tue Sep 19, 2006 8:42 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
tleichen
PostPosted: Tue Sep 19, 2006 10:14 am    Post subject: Reply with quote

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
View user's profile Send private message
Ivans
PostPosted: Tue Sep 19, 2006 11:24 am    Post subject: Reply with quote

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
View user's profile Send private message
HubertKleinmanns
PostPosted: Tue Sep 19, 2006 10:33 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
Ivans
PostPosted: Tue Sep 19, 2006 11:41 pm    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum Index » Clustering » QALIAS Put goes to wrong clustered QLOCAL ignoring CLWLPRTY
Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.