| Author |
Message
|
| jcv |
 Posted: Thu May 08, 2008 12:18 am Post subject: preferred instance of a clustered queue |
 |
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
Hello,
I have more than one instance of a clustered queue hosted on remote qmgrs, and my server application needs to put reply message to a specific one obtained from ReplyToQMgr attribute of request, but if that qmgr becomes unavailable, I'd rather put it in any other instance, than wait for this qmgr to become available. How do I manage that? Setting qmgr in MQOD to ReplyToQmgr on queue opening seems to fix destination without cluster workload possibility to choose other instances, while CLWL priorities enable preferrences globaly and statically (not at put msg time), and they are not supposed to be changed by applications which are connected to another qmgr. That is, they don't seem to fit for that purpose. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu May 08, 2008 1:35 am Post subject: Re: preferred instance of a clustered queue |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| jcv wrote: |
| I have more than one instance of a clustered queue hosted on remote qmgrs, and my server application needs to put reply message to a specific one obtained from ReplyToQMgr attribute of request, but if that qmgr becomes unavailable, I'd rather put it in any other instance, than wait for this qmgr to become available. |
Your design can't have it's cake and eat it too. Either the reply needs to go to a specific queue manager (typically because the requestor is connected to that queue manager and is waiting) or it can be processed by any queue manager on the reply side.
If, as you imply, the reply can be processed by any queue manager then just distribute them. If it needs to be addressed to a particular queue manager then this implies no other queue manager has the relevant data to process it.
Obviously an HA solution would prevent a queue manager becoming unavailable.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| jcv |
| Posted: Thu May 08, 2008 2:07 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
| To a certain extent I agree with you, but not completely. This question is driven by my colleague application developer who says he is going to wait connected to a local qmgr, and if response does not return, or if he gets qmgr quiescing or qmgr stopping or connection broken, or whatever rc it might be, he is going to connect to the other qmgr (there are actually only two of them for that purpose) trying to collect response there. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu May 08, 2008 2:12 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| jcv wrote: |
| This question is driven by my colleague application developer who says he is going to wait connected to a local qmgr, and if response does not return, or if he gets qmgr quiescing or qmgr stopping or connection broken, or whatever rc it might be, he is going to connect to the other qmgr (there are actually only two of them for that purpose) trying to collect response there. |
What will he do if the responses takes longer than expected to return? Under this principle his application will be continuously jumping from queue manager to queue manager, always reading one response back. Another problem with this design is it doesn't scale - what will happen if a third queue manager is added? Or a fourth?
What he should do is ensure both request & response have an expiry period set matching the period of time his application will wait for a response. If the application is forced to disconnect & reconnect it should reissue the last request.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| jcv |
| Posted: Thu May 08, 2008 3:44 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
If response takes longer than expected to return, he will do the same kind of thing as if he did not try to collect response elsewhere, after failing to collect it on that qmgr. What will it be exactly, I don't know and that's not the point here. He is driving it on the assumption that these are going to be rare exceptions rather than common condition.
The main problem here is actually that this collecting is not done automatically by MQ in some of its layers, because there is no possibility to "connect to a cluster of qmgrs", application can only connect to a particular qmgr, and application must take care of such things by itself. Isn't it?
Regarding scalability you are right. I've already told him so, but he is persistent. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Thu May 08, 2008 3:47 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
@jcv
what happened when you tried?
I recall having a discussion long time ago, that there is some 'magic' in the cluster logic if a message is on a cluster xmit queue and the channel is not available/retrying the cluster algorithm will look around for another destination, despite the mqmd setting of transmission header to a specific queuemanager.
ofcourse this does not apply to messages that are already 'in' the channel when the destination qmgr goes down...
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu May 08, 2008 3:53 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Michael Dag wrote: |
| ofcourse this does not apply to messages that are already 'in' the channel when the destination qmgr goes down... |
How can something be "in" the channel? If the MCA's got a problem the message will roll back onto the xmitq surely?
I thought the "destination fixed" was the reason messages got stuck in the "using WMQ for HA failover" scenario. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| jcv |
| Posted: Thu May 08, 2008 3:55 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
| Whenever I tried with setting qmgrname in MQOD, if qmgr was unavailable, ie/or channels to that particular qmgr were not running messages just stood there in xmitq waiting for channel to reestablish. So, there is some magic which can change the destination qmgr? Which exactly? |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu May 08, 2008 4:04 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| jcv wrote: |
| Whenever I tried with setting qmgrname in MQOD, if qmgr was unavailable, ie/or channels to that particular qmgr were not running messages just stood there in xmitq waiting for channel to reestablish. |
Now this is exactly what I'd have expected to happen.
| jcv wrote: |
| So, there is some magic which can change the destination qmgr? Which exactly? |
It can be changed manually,by editing the xmit headers, but I don't think that's really what you want to be doing.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Thu May 08, 2008 4:05 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| Vitor wrote: |
| Michael Dag wrote: |
| ofcourse this does not apply to messages that are already 'in' the channel when the destination qmgr goes down... |
How can something be "in" the channel? If the MCA's got a problem the message will roll back onto the xmitq surely?
I thought the "destination fixed" was the reason messages got stuck in the "using WMQ for HA failover" scenario. |
I had this discussion with Ian, maybe I misunderstood (I never reallly tried so I have no PROOF...)
I don't think retrying cluster sndr channels automatically roll back messages onto the cluster xmit queue... so those messages are 'in' the channel when the other end goes down...
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu May 08, 2008 4:08 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Paging any passing IBMer - will any passing IBMer (especially those who know magic or are called Ian) please pick up?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Thu May 08, 2008 4:09 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| jcv wrote: |
| Whenever I tried with setting qmgrname in MQOD, if qmgr was unavailable, ie/or channels to that particular qmgr were not running messages just stood there in xmitq waiting for channel to reestablish. So, there is some magic which can change the destination qmgr? Which exactly? |
please define 'not running', you mean stopped or retrying or inactive (should not be the case this one...) and how many messages did you send to try, was the number larger than your batch size or less?
again, I had this discussion with Ian from Hursley, and maybe I completely misunderstood...
What I got from the discussion is that there is some 'last minute' decision process depending on certiain criteria that the message is sent to another available destination in the cluster...
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu May 08, 2008 4:14 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Michael Dag wrote: |
again, I had this discussion with Ian from Hursley, and maybe I completely misunderstood...
|
Or maybe not.
I know Ian haunts the forum periodically, so perhaps there will be clarification.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu May 08, 2008 4:15 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Whatever the resolution of the stuck message question is, my comments earlier about the weaknesses of this application design stand.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Thu May 08, 2008 4:20 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| Vitor wrote: |
| Whatever the resolution of the stuck message question is, my comments earlier about the weaknesses of this application design stand. |
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
|
|
