| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Round Robin of the messages doesn't look up to the marks. |
« View previous topic :: View next topic » |
| Author |
Message
|
| mqjeff |
 Posted: Wed Apr 01, 2009 7:59 am Post subject: |
 |
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Let me try one more time.
If you set the Destination QMgr to a non-null value , then Cluster Workload balancing will NEVER occur.
This is what you WANT. You do not WANT a Reply message to a requestor that is listening on Qmgr A to be loadbalanced and end up on QmgrB.
In addition, you are only SOMETIMES honoring your ReplyToQmgr value, based on whether or not some other part of your flow that you have not shown nor discussed sets Environment.Variables.Override.ReplyQM.
It's not at all clear why you would ever have that Override value set, either. It makes no sense in any kind of request/reply scenario, nor in any other kind of response scenario. But that's separate from your perception of a problem. |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Wed Apr 01, 2009 8:54 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
The usual request-reply model (clustered or not) assumes that the replies come back to the requesting application. Usually, the request messages are destined for clustered request queues. The workload balancing of outbound request works as designed. Most request-reply app designs bind together the requesting application to the reply message.
If your design doesn't require that the requesting app get its reply back, then you are really looking at a modified asynchronous request-reply model - one where replies go to a third (or fourth or fifth) queue/qmgr for asynchronous processing.
If this is the case, then both request queues and reply-to-queues can be clustered.
_________________
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 |
|
|
| shashivarungupta |
| Posted: Wed Apr 08, 2009 9:19 pm Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
| mqjeff wrote: |
Let me try one more time.
If you set the Destination QMgr to a non-null value , then Cluster Workload balancing will NEVER occur.
This is what you WANT. You do not WANT a Reply message to a requestor that is listening on Qmgr A to be loadbalanced and end up on QmgrB.
In addition, you are only SOMETIMES honoring your ReplyToQmgr value, based on whether or not some other part of your flow that you have not shown nor discussed sets Environment.Variables.Override.ReplyQM.
It's not at all clear why you would ever have that Override value set, either. It makes no sense in any kind of request/reply scenario, nor in any other kind of response scenario. But that's separate from your perception of a problem. |
I appreciate your involvement.
Whenever a message is put by a client application Or requesting system (req-rep scenario) it is supposed to mention a ReplyToQM and ReplyToQueue.
IF Environment.Variables.Override.ReplyQM IS NOT NULL THEN
SET ReplyQM = Environment.Variables.Override.ReplyQM;
ELSE
SET ReplyQM = InputRoot.MQMD.ReplyToQMgr;
END IF;
In this override functionality, the appli. team can set the ReplyToQM and ReplyToQueue parameters which are then overridden in the code. If they are not passing then we can explicitly pass it in the code.
Its simple, when they are giving it then use it, and if they are not giving it then use the value at MQMD.
Believe me it works.
I agree upon the statement given by bruce2359 , right above.
In our case reply queues are shared and we want messages to go to any of the gateway queue managers (means round robin should work.)
Sorry for not being in touch for a while.
Thanks |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Apr 08, 2009 11:27 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| shashivarungupta wrote: |
| ...In our case reply queues are shared... |
To be pedantic, the term 'shared' applies only to z/OS-based queue manager objects where those queue managers are in a in a Queue Sharing Group; therefore, I assume you mean load-balanced.
_________________
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 |
|
|
| shashivarungupta |
| Posted: Thu Apr 09, 2009 12:12 am Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
| exerk wrote: |
| shashivarungupta wrote: |
| ...In our case reply queues are shared... |
To be pedantic, the term 'shared' applies only to z/OS-based queue manager objects where those queue managers are in a in a Queue Sharing Group; therefore, I assume you mean load-balanced. |
Yes, you are right. I mean load balanced or Visible in cluster. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Apr 09, 2009 2:41 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20757
Location: LI,NY
|
| shashivarungupta wrote: |
| exerk wrote: |
| shashivarungupta wrote: |
| ...In our case reply queues are shared... |
To be pedantic, the term 'shared' applies only to z/OS-based queue manager objects where those queue managers are in a in a Queue Sharing Group; therefore, I assume you mean load-balanced. |
Yes, you are right. I mean load balanced or Visible in cluster. |
This means that you really have an asynchronous request/reply setup where the consumption of the reply is load balanced in the cluster.
What has worked best, in my experience, to achieve this kind of a result, is to set up a cluster alias and to use it in the replyto qmgr field. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| shashivarungupta |
| Posted: Thu Apr 09, 2009 3:26 am Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
| fjb_saper wrote: |
| shashivarungupta wrote: |
| exerk wrote: |
| shashivarungupta wrote: |
| ...In our case reply queues are shared... |
To be pedantic, the term 'shared' applies only to z/OS-based queue manager objects where those queue managers are in a in a Queue Sharing Group; therefore, I assume you mean load-balanced. |
Yes, you are right. I mean load balanced or Visible in cluster. |
This means that you really have an asynchronous request/reply setup where the consumption of the reply is load balanced in the cluster.
What has worked best, in my experience, to achieve this kind of a result, is to set up a cluster alias and to use it in the replyto qmgr field. |
| Quote: |
| ...to achieve this kind of a result, is to set up a cluster alias and to use it in the replyto qmgr field. |
Wow... Frankly I never tried such thing.
AFAIK..
"There are three types of alias; queue-manager aliases, reply-to queue aliases, and queue aliases. These apply in a clustered environment just as well as in a distributed-queuing environment."
Could you please guide me how to set up a cluster alias? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Apr 09, 2009 3:33 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| A "cluster alias" is a qremote that has no RQMNAME. |
|
| Back to top |
|
|
| shashivarungupta |
| Posted: Thu Apr 09, 2009 3:35 am Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
| mqjeff wrote: |
| A "cluster alias" is a qremote that has no RQMNAME. |
I got you ... |
|
| Back to top |
|
|
| shashivarungupta |
| Posted: Wed Apr 15, 2009 12:48 am Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
| shashivarungupta wrote: |
| Vitor wrote: |
If you think that the software isn't doing what it's being asked to raise a PMR - software has things we call "bugs" in it sometimes and it's plausible you've found one. It's equally plausible that the software is doing exactly what it's being asked to do, rather than what you expected it to do.
The top tip with clusters behaving oddly is to ensure all the cluster sender/receiver channels are running. If they are, and it's still not behaving as you expect, raise a PMR as I suggest above. |
Thanks Vitor.
We have opened the PMR with IBM.
And If I'll get some answer / solution to this issue, i'll post it over here.
Appreciate all your quick responses.
 |
Here we have had discussion with IBM and they have suggested to install a fixpack WebSphere MQ V6.0 Fix Pack 6.0.2.5
http://www-01.ibm.com/support/docview.wss?rs=171&uid=swg1IZ23058
They say..this may resolve the issue of uneven load sharing in the cluster between queue managers.
As a separate note: if the queue, that is clustered among queue managers and having multiple instances with same name on more then one queue managers, to be deleted from the cluster queue manager(s) then it 'must' be first unshared from that cluster then removed/deleted.
If this is not done then This might cause an issue as I have faced. |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Apr 15, 2009 1:09 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| shashivarungupta wrote: |
| ...As a separate note: if the queue, that is clustered among queue managers and having multiple instances with same name on more then one queue managers, to be deleted from the cluster queue manager(s) then it 'must' be first unshared from that cluster then removed/deleted. |
Which is 'standard' good practice, and should be explicitly stated in the process document in which you specify cluster maintenance - your site/team does have such a document I presume?
_________________
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 |
|
|
| shashivarungupta |
| Posted: Wed Apr 15, 2009 1:19 am Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
| exerk wrote: |
| shashivarungupta wrote: |
| ...As a separate note: if the queue, that is clustered among queue managers and having multiple instances with same name on more then one queue managers, to be deleted from the cluster queue manager(s) then it 'must' be first unshared from that cluster then removed/deleted. |
Which is 'standard' good practice, and should be explicitly stated in the process document in which you specify cluster maintenance - your site/team does have such a document I presume? |
 Ya. We do have.
 |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
