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 » cluster workload balancing when App binds with alias queue

Post new topic  Reply to topic Goto page 1, 2  Next
 cluster workload balancing when App binds with alias queue « View previous topic :: View next topic » 
Author Message
sijtom0703
PostPosted: Sat Aug 16, 2014 6:20 am    Post subject: cluster workload balancing when App binds with alias queue Reply with quote

Voyager

Joined: 28 May 2011
Posts: 84
Location: USA

We have a serious technical issue with our new WebSphere MQ 7.5 design. We have some of the queues in Windows platform in distributed MQ and the newly migrated queues in Linux platform in Clustered MQ . We are using gateway queue managers (two of them) in cluster to perform the complete migration of queues from Windows to Linux.

Currently for outbound messages from Linux to Windows we have an Application Alias queue (not shared in cluster) defined in a Linux App queue manager. A cluster remote queue is defined in the gateway queue manager in Linux. Both App queue manager and gateway queue manager share the same cluster. The remote cluster queue then has XmitQ and Sender/Receiver channels to Windows distributed MQ. The issue here is whenever one gateway queue manager goes down the Application binding is not switching to the other instance of the gateway cluster remote queue. Instead even new messages put are also getting stuck in cluster transmit queue of the App queue manager. The binding used is DEFBIND - NOTFIXED.

Can anyone provide a solution which will enable cluster workload balancing on our gateway queues? Appreciate any advice.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Sat Aug 16, 2014 7:33 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
Location: US: west coast, almost. Otherwise, enroute.

Moved to Clustering forum.
_________________
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
View user's profile Send private message
bruce2359
PostPosted: Sat Aug 16, 2014 7:36 am    Post subject: Re: cluster workload balancing when App binds with alias que Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
Location: US: west coast, almost. Otherwise, enroute.

sijtom0703 wrote:
The binding used is DEFBIND - NOTFIXED.

Where exactly is the binding specified as NOT_FIXED? In the program that MQOPENs the queue and produces the message? In the QAlias definition?
_________________
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
View user's profile Send private message
sijtom0703
PostPosted: Sat Aug 16, 2014 8:12 am    Post subject: Reply with quote

Voyager

Joined: 28 May 2011
Posts: 84
Location: USA

Thanks! and sorry for posting in wrong forum.

The binding is specified in the Cluster remote queue mentioned in my post.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Sat Aug 16, 2014 9:19 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
Location: US: west coast, almost. Otherwise, enroute.

The BIND specification on a queue definition will be used only if the application specified BIND_AS_Q_DEF.

What did the application specify? BIND_ON_OPEN? BIND_NOT_FIXED?
_________________
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
View user's profile Send private message
dware
PostPosted: Mon Aug 18, 2014 12:55 am    Post subject: Reply with quote

Novice

Joined: 18 Nov 2013
Posts: 13

If the application uses MQOO_BIND_AS_Q_DEF then it will pick up the bind option from the thing it opens, which in this case is the queue alias not the clustered remote queue. So you need to set NOTFIXED on the alias queue, even though it is not clustered.

David.
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Mon Aug 18, 2014 4:51 am    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY

If my understanding of your problem is correct, your return path is the one having the problem.

This means you need to have a default return path that is defined on each of the gateways and SHARED in the cluster. It also needs to have a bindings set as not fixed so that when a message gets put the 2 gateways get load balanced.

If the gateways don't get load balanced you should look to make sure the application does put the reply message with option bindings not fixed or at least binding group.

Have fun
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
JosephGramig
PostPosted: Mon Aug 18, 2014 5:38 am    Post subject: Reply with quote

Grand Master

Joined: 09 Feb 2006
Posts: 1230
Location: Gold Coast of Florida, USA

This is one of my pet peeves about MQ. I wish I could specify the default DEFBIND to be NOTFIXED on creation of the Qmgr for all queues. I always change this on SYSTEM.DEFAULT.(ALIAS, LOCAL, REMOTE).QUEUE queues immediately after creation.

If an application does need to BIND on open, then is should specify such on the open options.
Back to top
View user's profile Send private message AIM Address
mqjeff
PostPosted: Mon Aug 18, 2014 5:48 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

I really can't tell which direction is having the problem.

It's not at all clear that reply messages should be load-balanced across the cluster.

It does make sense if one is using two queue managers with identical routes to move from cluster-to-non-cluster.

But then the application that's sending the reply does have to use bind-not-fixed, which is not usually what one wants when sending reply messages.... because one usually expects that there's a single replytoqueue that's got the "right" application listening to it.

If you later on move your requesting applications (the client apps) to talk to queue managers in the cluster, you may find that your replies are now misdirected.

Probably best to draw some diagrams of your topology and show the moving parts that you're having to work with. Then walk through "application A connects to qmgr x, and sends message to queue Y", and then track the resolution of queue Y across the network, and do the same for the reply.

Or you could turn on trace route messages...
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Mon Aug 18, 2014 6:32 am    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY

mqjeff wrote:

If you later on move your requesting applications (the client apps) to talk to queue managers in the cluster, you may find that your replies are now misdirected.

Or you could turn on trace route messages...

Don't quite understand your assumption. You're not removing any reply to qmgr information.
The reply to qmgr just happens to resolve to 2 qmgr aliases (remote queues) (one on each gateway) that are shared in the cluster and correctly move the message out of the cluster...
If at a later time you move your application into the cluster the reply-to destination will become unique (in the cluster), therefore no more load balancing... no changes...
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
PeterPotkay
PostPosted: Mon Aug 18, 2014 12:28 pm    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

The topology is not clear to me either. What exactly is a "remote cluster queue "? Oh yeah? Read the original post again, maybe not.

Until we see the actual queue definitions, as well as what is being used for MQOPEN options and Destination QM on the MQOPEN call, we are just guessing.

And while it can be set up to load balance out bound messages to leave the cluster across 2 gateway QMs, what's the plan for messages coming back into the cluster. Granted, that was specifically called out....yet.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
sunny_30
PostPosted: Thu Aug 21, 2014 9:52 am    Post subject: Reply with quote

Master

Joined: 03 Oct 2005
Posts: 258

dware wrote:
If the application uses MQOO_BIND_AS_Q_DEF then it will pick up the bind option from the thing it opens, which in this case is the queue alias not the clustered remote queue. So you need to set NOTFIXED on the alias queue, even though it is not clustered.
David.

If the AliasQ is not clustered and app specifies MQOO_BIND_AS_Q_DEF - The BIND option set on the AliasQ doesnt matter
As per MQv7.5 InfoCenter:
Quote:
DefBind (MQLONG)
This is the default binding that is used when MQOO_BIND_AS_Q_DEF is specified on the MQOPEN call and the queue is a cluster queue.

Well, even if the AliasQ is clustered, app specifies MQOO_BIND_AS_Q_DEF, the bind options on BaseQ override the options set on AliasQ
Back to top
View user's profile Send private message
dware
PostPosted: Fri Aug 22, 2014 12:36 am    Post subject: Reply with quote

Novice

Joined: 18 Nov 2013
Posts: 13

I'm afraid I disagree with this, although the documentation is not very clear. Have you tried this?

I think the documentation you reference is just being over simplistic and trying to indicate that DefBind applies only when cluster routing is in play (as it is in this case). There is a more explicit reference here http://www-01.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.ref.dev.doc/q101870_.htm?lang=en, see note 3 on MQOO_BIND_* options following the options table (although admittedly just as cryptic in my mind!):

Quote:
This option can be specified for any queue type, but is ignored if the queue is not a cluster queue. However, the DefBind queue attribute overrides the base queue even when the alias queue is not in a cluster.


There was an APAR way back at 6.0.2.3 which fixed the behaviour to be as I've explained. http://www-01.ibm.com/support/docview.wss?uid=swg1IZ07794

Generally, attributes that can be set on a queue alias override those of the target queue.
Back to top
View user's profile Send private message
sunny_30
PostPosted: Fri Aug 22, 2014 1:46 am    Post subject: Reply with quote

Master

Joined: 03 Oct 2005
Posts: 258

dware wrote:
I'm afraid I disagree with this, although the documentation is not very clear. Have you tried this?
Yes tested using v7502 but not setting the env variable as listed in the APAR link you provided
Back to top
View user's profile Send private message
dware
PostPosted: Fri Aug 22, 2014 2:12 am    Post subject: Reply with quote

Novice

Joined: 18 Nov 2013
Posts: 13

Strange, what are we doing differently?

That environment variable looks to be a temporary V6 service stream only requirement, the behaviour since V7 has been as described (the alias takes precedence). I did the following test (no environment variable set!) and got the behaviour as I described:

QMGR1, QMGR2 and QMGR3 in a cluster.

QMGR1:
DEFINE QL(Q1) CLUSTER(CLUSTER1) DEFBIND(NOTFIXED)

QMGR2:
DEFINE QL(Q1) CLUSTER(CLUSTER1) DEFBIND(NOTFIXED)

QMGR3:
DEFINE QA(QA) TARGET(Q1) <--- Resulting in the default of DEFBIND(OPEN)

Then put several messages using "amqsput QA QMGR3"

This sends all the messages through to Q1 or QMGR1 or Q1 on QMGR2, i.e. BindOnOpen behaviour.

If I put several messages using "amqsput Q1 QMGR3" I get an even distribution, i.e. BindNotFixed behaviour.

What setup did you use to test this and get the behaviour you've described?
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 » cluster workload balancing when App binds with alias queue
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.