| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| preferred instance of a clustered queue |
« View previous topic :: View next topic » |
| Author |
Message
|
| jcv |
 Posted: Thu May 08, 2008 5:20 am Post subject: |
 |
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
| I have tried to send a message or two, while cluster sender channel status was retrying because targeted qmgr was quiescing. Messages were stuck in SCTQ. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Thu May 08, 2008 5:58 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20757
Location: LI,NY
|
This is expected behavior. Your message is destination specific (qmgr has been asked for at put time). No algorithm is going to send it round robin. In order to get to a destination on the cluster using the round robin algorithm you should specify a blank qmgr name in the MQMD.
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu May 08, 2008 6:08 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| fjb_saper wrote: |
In order to get to a destination on the cluster using the round robin algorithm you should specify a blank qmgr name in the MQMD.
|
In the context of the previous discussion, once the message has been queued for delivery to a specific queue manager (via the workload algorithm if no destination is specified) do you believe the destination will be reset if the original destination becomes unavailable?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| jcv |
| Posted: Thu May 08, 2008 8:08 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
| fjb_saper wrote: |
| This is expected behavior. Your message is destination specific (qmgr has been asked for at put time). No algorithm is going to send it round robin. In order to get to a destination on the cluster using the round robin algorithm you should specify a blank qmgr name in the MQMD. |
That's fine and understandable. Hence, there is no way to tell to the default CLWL algorithm the preferred qmgr destination for the particular message, at put time? I mean without being strictly destination specific, in which case that algorithm will always yield the asked destination, or it will be bypassed in the first routing decision step? |
|
| Back to top |
|
|
| jcv |
| Posted: Thu May 08, 2008 8:43 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
That may be true, but there is a document which explains that messages may be routed (reallocated) to another queue manager:
http://www-1.ibm.com/support/docview.wss?uid=swg21127527
I don't know if this may happen only if they were put to a queue originally opened with qmgr blank, it only states that MQOO_BIND_NOT_FIXED option should be used. We are actually discussing here options that we may choose at open time, not at put time. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu May 08, 2008 9:35 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
If the message is trying to go to Queue1 on QMA because the putting app specifically said to go to QMA, or opened the queue with the Bind option, than that message will only try and go to QMA no matter how long QMA is down.
If the message is trying to get to Queue1 on QMA because the cluster load balancing choose that destination but before it could actually ship it QMA became N/A, the message will be rerouted to another QM that hosts Queue1 the next time the channel retries.
jcv, looks like you need to have 2 instances of your sending app listening, one connected to each QM that hosts your reply queue. In that case it doesn't matter which QM produces the request, the reply comes back to the clustered queue not tied to any one QM so MQ clustering magic will get it to one of the two QMs, both of which have your app waiting for the reply.
Even with H.A. queue managers there is downtime as the QM fails over. Using mutiple putters and getters and not tying the reply to any one QM provides the ultimate in availability. Well, adding z/OS shared queues into the picture would make it even better.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| 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
|
|
|
|
