| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| To queiesce a queue manager |
« View previous topic :: View next topic » |
| Author |
Message
|
| awatson72 |
 Posted: Mon Apr 20, 2009 9:42 am Post subject: To queiesce a queue manager |
 |
|
Acolyte
Joined: 14 Apr 2004
Posts: 69
Location: Freeport, Maine
|
I'm curious as to what people do to gracefully bring a queue manager off-line without adversely impacting connecting applications -
Assume a queue manager which handles JMS traffic via SVRCONN channels, handles MQ API traffic via SVRCONN channels, and handles basic sender/reciever traffic.
If I stop the listener without doing anything with the channels, what happens to the currently running channels? Looks to me like they stay active, they stay in Status - Running, they appear on the server as TCP connections, and when looking at channel status, "messages" continue to flow through. Maybe these "messages" which are showing up, (based on "Last Message Time") are not actually messages? Should I be stopping these running channels before shutting down the queue manager? For the applications using the MQ API, the application architecture is such that applications will fail-over to a second queue manager if the connection attempt fails to connect to the SVRCONN on the first queue manager. I guess what I'm trying to get to the bottom of is whether or not stopping the listener *really* closes the door on the QM. I have doubts because of the TCP connections I see established, which correspond to the channels that don't go inactive, and the fact that in at least one case, a remote QMs sender channel to the reciever to the QM with the downed listener did NOT go into retry mode. Just trying to understand more about how this is supposed to work.
Thanks.
_________________
Andrew Watson
L.L. Bean, Inc. |
|
| Back to top |
|
 |
| bbburson |
| Posted: Mon Apr 20, 2009 9:46 am Post subject: |
|
|
Partisan
Joined: 06 Jan 2004
Posts: 378
Location: Nowhere near a queue manager
|
| Stopping the listener prevents new connections to the queue manager. It does not affect connections that are already established. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Apr 20, 2009 10:00 am Post subject: Re: To queiesce a queue manager |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| awatson72 wrote: |
| I'm curious as to what people do to gracefully bring a queue manager off-line without adversely impacting connecting applications |
It's very hard to take the the queue manager off line without causing an outage in the connecting applications. Much like you can't bring a database down without having some kind of impact....
As a standard the applications should be coded to finish what they're doing and terminate when the queue manager signals that it's trying to quiecse.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Apr 20, 2009 10:05 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| to gracefully bring a queue manager |
For distributed platforms, the endmqm control command has three flavors:
Controlled quiesce: endmqm -c
This allows all MQCONNected applications to continue to MQDISC; but no new MQCONNections.
Immediate Quiesce: endmqm -i
This allows all currently executing MQI calls to complete; but no new MQI calls.
Premptive quiesce: endmqm -p
All current MQI calls are failed.
In all cases, the qmgr will end the channels, and the qmgr ends normally.
Well-behaved apps will include the FAIL__IF_QUIESCING option on all MQI calls; and end the app appropriately (comit or backout changes) when the qmgr returns the qmgr quiescing reason code.
Doesn't the -c option satisfy your desire for applications to not be affected adversely?
_________________
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 |
|
|
| exerk |
| Posted: Mon Apr 20, 2009 11:38 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| bruce2359 wrote: |
...Immediate Quiesce: endmqm -i
This allows all currently executing MQI calls to complete; but no new MQI calls... |
Also, not forgetting that incomplete units of work will be rolled back on restart.
_________________
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 |
|
|
| PeterPotkay |
| Posted: Mon Apr 20, 2009 12:41 pm Post subject: Re: To queiesce a queue manager |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| awatson72 wrote: |
| Maybe these "messages" which are showing up, (based on "Last Message Time") are not actually messages? |
On a SVRCONN channel, a "message" is an MQ API call or its results. MQOPEN is 2 messages - the request and the result. MQGET that returns a 2033 is 2 "messages" - the request and the result. MQGET that returns an app message is 2 "messages" - the request and the result.
Just stop the listener, then issue endmqm -i. If you have a dopey app that didn't code FAIL_IF_QUIESCING, you don't want to be at their mercy waiting all night for the QM to come down, so use -i. If you have another dopey app that drops into a reconnect loop as fast as it can over and over, you don't want the ending QM to be busy with recording all the results of the failed connection attempts in its logs, so that's why you might want to stop the Listener before the QM.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| awatson72 |
| Posted: Tue Apr 21, 2009 5:01 am Post subject: |
|
|
Acolyte
Joined: 14 Apr 2004
Posts: 69
Location: Freeport, Maine
|
Thanks - great info.
This case was a little unusual in that we were conducting a "live" test, (don't ask - long story), and never planned to stop the QM, only to stop traffic coming into it, thinking we would do so by stopping the listener. I'm learning that stopping the listener won't do it, that the QM needs to stop, or something drastic has to happen like the TCP stack has to be torn down on the OS. Regarding app behavior, most should be coded MQ-friendly with fail if quiescing, but some I'm sure are not. So it sounds like better QM down procedures involve using endmqm -i, or endmqm -c. What about stopping channels, either before or after stopping the listener? Do any admins out there incorporate that action into their process? I'm sure the answer will depend somewhat on the nature of the connection app.
_________________
Andrew Watson
L.L. Bean, Inc. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Apr 21, 2009 5:19 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| awatson72 wrote: |
| Do any admins out there incorporate that action into their process? |
FWIW I never bother to stop either channel or listener manually, leaving the queue manager to handle that.
In the event an application is not coded to play nice, I augment the endmqm -i with a process that identifies the application in question before issuing the endmqm -i, then explaining to the application team responsible why they need to change their code. Repeatedly and quite hard.
 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
