| Author |
Message
|
| subbu |
 Posted: Tue Dec 08, 2009 5:36 am Post subject: How to stop a queue manager which is in ending state |
 |
|
Newbie
Joined: 26 Nov 2009
Posts: 8
|
| Hi friends, I stopped a queuemanager, but it is not stopped and it is always saying it is in ending state. it is not possible neigther starting or deleting. How to solve this? |
|
| Back to top |
|
 |
| exerk |
| Posted: Tue Dec 08, 2009 5:47 am Post subject: Re: How to stop a queue manager which is in ending state |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| subbu wrote: |
| Hi friends, I stopped a queuemanager, but it is not stopped and it is always saying it is in ending state. it is not possible neigther starting or deleting. How to solve this? |
Next time you post, please check into which forum you are posting - this was in the Challenge forum (I've since moved the post).
Furthermore, you can find the answers in the System Administration Guide (SAG).
_________________
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 |
|
|
| bruce2359 |
| Posted: Tue Dec 08, 2009 6:29 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Control command endmqm has additional switches that determine the type of shutdown (and what workload can continue to successful completion). Each switch is discussed in the WMQ System Admin manual:
endmqm -c is controlled quiesce
endmqm -i immediate
endmqm -p preemptive
_________________
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 |
|
|
| csmith28 |
| Posted: Tue Dec 08, 2009 7:48 am Post subject: |
|
|
Grand Master
Joined: 15 Jul 2003
Posts: 1196
Location: Arizona
|
ps -ef | grep mqm | grep -v grep | awk '{print $2}' | xargs kill -9
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Dec 08, 2009 10:22 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
kill -9 is a wonderful technical solution; but a really bad business solution.
The same is true of endmqm -i and -p.
_________________
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 |
|
|
| PeterPotkay |
| Posted: Tue Dec 08, 2009 12:34 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| bruce2359 wrote: |
kill -9 is a wonderful technical solution; but a really bad business solution.
The same is true of endmqm -i and -p. |
If FAIL_IF_QUIESCING was the default on all MQ API calls, I would agree with you on endmqm -i. But since the lack of FAIL_IF_QUIESCING being coded is most often due to ignorance and/or laziness, versus a conscience decision based on business requirements, I always (have to) use endmqm -i. Otherwise I'd still be waiting for that endmqm to end that I issued months ago.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Dec 08, 2009 1:39 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| I always (have to) use endmqm -i. |
I'll agree that if your computer room is burning down, and you want to shut down the servers, -i and -p are wonderful tools. However, these are not best-practices.
I'd push this back to developers and management with appropriate warnings that real business data may be lost. I've had success dragging auditors into this exact discussion.
If implicit policy (lack of a policy that dictates FAIL_IF), then the policy needs to change - not the behavior of sysadmins.
_________________
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: Tue Dec 08, 2009 2:04 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| bruce2359 wrote: |
| ...I'd push this back to developers and management with appropriate warnings that real business data may be lost. I've had success dragging auditors into this exact discussion... |
Unfortunately I've seen, on more than one occasion, where a GET with an indefinite wait has been coded, and not just within in-house written applications. In just about all those cases it was felt the cost of fixing the apps was proportionally greater than the potential loss of data. Both you and I know it's just a case of changing one small thing, but developers start seeing the potential to rack up the hours because they have to regression test etc., and that's when a 'business' decision is taken to accept the status quo. Also, it's cheaper to just introduce a procedural change to make sure the app is brought down first.
_________________
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 |
|
|
| bruce2359 |
| Posted: Tue Dec 08, 2009 2:35 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Yes, reality.
This is where I've (ab)used auditors to document that poor programming practices may lead to loss of business data integrity. Once documented, my how-much-do-I-care-O-meter drops substantially.
_________________
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: Tue Dec 08, 2009 2:58 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| bruce2359 wrote: |
Yes, reality.
This is where I've (ab)used auditors to document that poor programming practices may lead to loss of business data integrity. Once documented, my how-much-do-I-care-O-meter drops substantially. |
Reality for me is mitigating the effects of much-cheapness applications produced in sweat-shops, and I see the same thing over-and-over where they have obviously not read the manual, but emailed their mates, who may have done it once, for scraps of code. And management seem strangely reassured when told by the developers that, of course we are adhering to standards 
_________________
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 |
|
|
| bruce2359 |
| Posted: Tue Dec 08, 2009 3:02 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Hmmm. Every time I lower my standards, others meet them.
_________________
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 |
|
|
| PeterPotkay |
| Posted: Tue Dec 08, 2009 3:05 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
How does endmqm -i cause data loss?
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/topic/com.ibm.mq.amqzag.doc/fa15800_.htm
| Quote: |
Immediate shutdown. The queue manager stops after it has completed all the MQI calls currently being processed. Any MQI requests issued after the command has been issued fail. Any incomplete units of work are rolled back when the queue manager is next started.
Control is returned after the queue manager has ended.
The effect on any client applications connected through a server-connection channel is equivalent to a STOP CHANNEL command issued in FORCE mode.
|
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Dec 08, 2009 3:24 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| Any incomplete units of work are rolled back when the queue manager is next started. |
Ah, you presume that all work is actually performed in UofW's, and with persistent messages. If only this were true.
The issue is best-practice coding... vs. the other kind.
_________________
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 |
|
|
| PeterPotkay |
| Posted: Tue Dec 08, 2009 5:01 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| bruce2359 wrote: |
| Quote: |
| Any incomplete units of work are rolled back when the queue manager is next started. |
Ah, you presume that all work is actually performed in UofW's, and with persistent messages. If only this were true.
The issue is best-practice coding... vs. the other kind. |
If you use non persistent messages, you accept data loss. endmqm does not make any difference compared to endmqm -i as it relates to data loss with non persistent messages.
If you issue an MQGET without syncpoint, you assume full responsability of the messages as soon as you get it. If the MQPUT is done without syncpoint, you are telling MQ the message is it's responsability as soon as the MQPUT completes successfully. Again, I don't see any difference between endmqm and endmqm -i if you are issuing calls with no syncpoint specified as it relates to data calls. MQGETs and MQPUTs will complete with endmqm -i just fine.
Its not realistic to rely on endmqm without -i on a QM where you don't have 100% control of every app and every app's coding. I refuse to be held hostage by an app's poor coding. If I need to take the QM down for maintenance I will assuming all change control processes have been followed. I'm still missing how endmqm -i can cause harm to data.
Take a look at the scripts that come with MC91 and how it progresses thru the various flags for endmqm. If a failover needs to occur it can't wait forever for some random app that didn't code FAIL_IF_QUIESCING.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mvic |
| Posted: Tue Dec 08, 2009 5:27 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| bruce2359 wrote: |
| -i and -p are wonderful tools. However, these are not best-practices. |
There is no reason not to use -i. (I wait to be corrected of course).
-i is indeed necessary unless all your applications are coded perfectly to observe qmgr quiescing and stopping conditions.
-p should indeed be reserved for panic situations.
UPDATE: Just spotted bruce's mention of apps that use non-reliable messaging. Well those apps "by design" have signed up for non-reliable messaging so they are getting part of what they signed up for when the qmgr ends without waiting for them to vote on the matter. |
|
| Back to top |
|
|
|
|
