| Author |
Message
|
| MQAltaf |
 Posted: Tue Nov 13, 2007 7:04 am Post subject: Suspending a Broker queue manager from a cluster |
 |
|
Centurion
Joined: 10 Feb 2005
Posts: 119
|
Hi,
Does anyone have any experience/best practice as to how to suspend a broker queue manager from a cluster considering that the broker may be waiting on responses whilst being suspended. What i need to know is whether suspending the broker queue manager will tale care of any in flight messages. I know that the suspend command will stop applications putting messages to the suspended queue manager but wanted to know if any requests intitated by the broker will complete before the queue manager is fully suspended. Is there are process that needs to be followed to overcome this
MQ version 6.0.2
Message Broker version 6
Thanks in advance |
|
| Back to top |
|
 |
| Vitor |
| Posted: Tue Nov 13, 2007 7:13 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Suspending the queue manager will stop new messages being sent to it by the cluster. If the broker has initiated a request, the reply will sit on the transmit queue until the queue manager is unsuspended (assuming it has a specific reply to queue manager and isn't distributed over the cluster).
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| MQAltaf |
| Posted: Tue Nov 13, 2007 7:29 am Post subject: |
|
|
Centurion
Joined: 10 Feb 2005
Posts: 119
|
Hi,
Thanks for the response.
I guess persistent messages sat in the transmit queue waiting to get back to the client that sent the requests are ok. However most of teh requests to the broker are non persistent and have an expiry. A typical scenario is for a client to send a request message which has a timeout of 30 seconds and an expiry of 60 seconds. The request received by the broker may call a number of services (send 4 four different messages) wait for a response and then send back to the client. If the queue manager is suspended whilst the broker is waiting for the responses to the four messages then i guess the client wont get a response to its request as the queue manager has been suspended? |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Nov 13, 2007 7:32 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Even a persistent message with an expiry will go at it's allotted time.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| MQAltaf |
| Posted: Tue Nov 13, 2007 7:34 am Post subject: |
|
|
Centurion
Joined: 10 Feb 2005
Posts: 119
|
Yes meant messages sent with an expiry/timeout
Is there no way around this? |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Nov 13, 2007 7:40 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Depends why you're suspending the queue manger & what version of WMQ you're using. If it's for routine maintenance pick a window when client activity is nill (I find 3am a good time). If you're on v6, change the cluster parameters to route work away from the queue manager in question, wait until it's finished then suspend it.
That sort of thing might also work on lower versions - if you put disable the queue the broker reads requests from it'll be eliminated from the workload balancing; or should be! Try it in test before you try it in prod.... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| MQAltaf |
| Posted: Tue Nov 13, 2007 8:30 am Post subject: |
|
|
Centurion
Joined: 10 Feb 2005
Posts: 119
|
Hi,
The brokers are used 24*7 so client activity is never null! We are using MQ 6.0.2 so guess should be able to alter the CLWL use queue attribute and wait until it's finished then suspend it.
We consider the put disable option, however that would mean maintaing a a list of all local clustered queues....not ideall really but may be the only way |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Nov 13, 2007 8:35 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Your clients should be prepared to have some requests dropped.
They're already prepared for this if they're sending NP messages with expiry.
So it's not clear why it's an issue if the broker flows time out waiting for replies.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Nov 13, 2007 10:59 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
And remember that even though the suspension is immediate for the qmgr in question it may take some time to reach both FRs.
And if the suspend is done in mode quiesce the replies will still flow to the suspended qmgr when specified explicitely until it is shut down...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Nov 13, 2007 1:21 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Suspending a QM does not mean that no messages will ever go to it. All it means is that as new messages come in looking for distribution the suspended QM will not get any IF there are other queues in the cluster that can take them.
If there are no other eligible queues, the message will be sent to the suspended QM.
If the message is specifically addressed to this QM, it will still go to it suspended or not.
So if QM1 sends out a request message where the the Reply To QM is QM1, and then you suspend QM1, just wait long enough for all outstanding reply messages to come back to QM1, knowing that all new request messages will go to the other QMs.
How long do you wait? Well that depends on the apps. Hopefully all will be done in a few seconds. But you may have some request reply scenarios that take hours to complete. In that case suspend the QM a day or two before the planned outage. Or just deal with reply messages trying to come back to QM1 while you have it down. Or if possible write your applications so that reply message can go to any reply q in the cluster without any regard to which requester initiated it.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| MQAltaf |
| Posted: Tue Nov 13, 2007 2:23 pm Post subject: |
|
|
Centurion
Joined: 10 Feb 2005
Posts: 119
|
Hi,
Thanks for all the responses.
The main problem is that the message broker sends out a significant number of requests. If by suspending the queue manager all these timeout then the broker flow queues have lots of orphaned messages on them.
We have two messages broker queue manager in the cluster so if one is down all requests are routed to the one which is available.
Does the suspend command wait untill all in flight transactions are processed before it is fully suspended? |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Nov 13, 2007 4:36 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| MQAltaf wrote: |
| Does the suspend command wait untill all in flight transactions are processed before it is fully suspended? |
| PeterPotkay wrote: |
Suspending a QM does not mean that no messages will ever go to it. All it means is that as new messages come in looking for distribution the suspended QM will not get any IF there are other queues in the cluster that can take them.
If there are no other eligible queues, the message will be sent to the suspended QM.
If the message is specifically addressed to this QM, it will still go to it suspended or not.
So if QM1 sends out a request message where the the Reply To QM is QM1, and then you suspend QM1, just wait long enough for all outstanding reply messages to come back to QM1, knowing that all new request messages will go to the other QMs.
How long do you wait? Well that depends on the apps. Hopefully all will be done in a few seconds. But you may have some request reply scenarios that take hours to complete. In that case suspend the QM a day or two before the planned outage. Or just deal with reply messages trying to come back to QM1 while you have it down. Or if possible write your applications so that reply message can go to any reply q in the cluster without any regard to which requester initiated it. |
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Mon Nov 26, 2007 10:41 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
And remember, unless you changed the default, the queue is defined as DEFBIND(OPEN). So, the messages will go to the queue that was picked on open. I would go so far as to change the default to DEFBIND(NOTFIXED).
_________________
Joseph
Administrator - IBM WebSphere MQ (WMQ) V6.0, IBM WebSphere Message Broker (WMB) V6.1 & V6.0
Solution Designer - WMQ V6.0
Solution Developer - WMB V6.1 & V6.0, WMQ V5.3 |
|
| Back to top |
|
|
|
|
