| Author |
Message
|
| Sam Uppu |
 Posted: Thu Apr 09, 2009 9:22 am Post subject: endmqm & strmqm functionality |
 |
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
Hi Guys,
We are on MQ version 6.0.2.3 on Solaris.
An Application and MQ running on the same physical server and the app is connecting via Binding mode.
QM1 is the QMgr
1. When I stop the QMgr with endmqm QM1, the QMgr is never ending(waited for 10 minutes) and the status is: STATUS(Quiescing)
2. Then I did an immediate shutdown with the option '-i'
endmqm -i QM1
This time the QMgr is shutdown with the status: STATUS(Ended immediately).
and when I try to restart the QMgr, I am unable to restart and failing with the following information:
strmqm QM1
AMQ8041: The queue manager cannot be restarted or deleted because processes,
that were previously connected, are still running.
Process 29744 is still running.
Process 29763 is still running.
Process 29756 is still running.
Process 29752 is still running.
Process 29748 is still running.
Process 29760 is still running.
AMQ7018: The queue manager operation cannot be completed.
3. The above PIDs which are still running are from the app. When the application kills the above PIDs, I am able to start the QMgr but the app doesn't want to kill and restart their app.
Can anybody let me know or direct me to a link what could be the issue.
Thanks. |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Thu Apr 09, 2009 9:26 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
It's all the fault of the app.
They are not coding FAIL_IF_QUIESCING, and coding their GET to wait indefinitely, so they are never releasing their MQ connections so the qmgr can't stop.
This is a trout:  You have official approval to use it on the app team for failing to follow MQ best practices. |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Thu Apr 09, 2009 9:41 am Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
| mqjeff wrote: |
It's all the fault of the app.
They are not coding FAIL_IF_QUIESCING, and coding their GET to wait indefinitely, so they are never releasing their MQ connections so the qmgr can't stop.
This is a trout: You have official approval to use it on the app team for failing to follow MQ best practices. |
FAIL_IF_QUIESCING for both PUT and GET?.
| Quote: |
| coding their GET to wait indefinitely |
This one I am not sure how much they set. Need to check with the app team.
I found the below interval somewhere in the forum
gmo.waitInterval = 3000;
Does this value need to set as per the app's requirement or we can set 3000 or some other value?.
Thanks. |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Thu Apr 09, 2009 9:46 am Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
I know I could be asking some silly stupid questions and you guys can scold me if you feel like..
but I need to go with the right and a decent answer to the app team. |
|
| Back to top |
|
|
| vandi |
| Posted: Thu Apr 09, 2009 9:49 am Post subject: |
|
|
Acolyte
Joined: 13 Dec 2008
Posts: 67
|
Hey Sam,
Did you see any errors in FDC's and logs?
Thanks |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Apr 09, 2009 9:49 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Sam Uppu wrote: |
| Quote: |
| coding their GET to wait indefinitely |
This one I am not sure how much they set. Need to check with the app team.
I found the below interval somewhere in the forum
gmo.waitInterval = 3000;
Does this value need to set as per the app's requirement or we can set 3000 or some other value?.
Thanks. |
Think about what that value is used for, and set it appropriately.
Regarding your original question, I think its lame that an app can prevent an MQ Admin from restarting the QM, no matter what they have coded or failed to have coded.
And why the heck is FAIL_IF_QUIESCING not the default anyway?
Take a look at amqiclen. If you run that before you restart the QM, it should allow the QM to restart. We had this problem on Solaris with MDBs preventing the QM from coming up.
You'll find this post very interesting:
http://www.mqseries.net/phpBB2/viewtopic.php?t=12594&highlight=mdb
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Apr 09, 2009 9:57 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
MQGMO_FAIL_IF_QUIESCING.
There is no Wait on MQPut.
If they're using a wait time of 3000, then you should be able to specify endmqm normally and have it complete successfully after 3000 microseconds, assuming the app time has done the correct thing when they get the RC they'll get.
If they specify a Wait time of "unlimited", then your endmqm will *never* complete, UNLESS they specify MQGMO_FAIL_IF_QUIESCING. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Apr 09, 2009 11:08 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
It's one of those best-practice thingies to code FAIL_IF_QUIESCING for all MQI calls. This allows the application to take appropriate action when a sysadmin issues the endmqm -c.
MQGET with wait should only wait a short period of time (10 seconds? 1 minute?); and if the qmgr is NOT quiescing, re-issue the MQGET with wait; then repeat ad-nauseum.
If the qmgr is quiescing, the app should backout or comit changes, and end the application gracefully. Don't force the admin to use the -i or -p option, or to re-boot. These will resolve the sysadmin requirement to stop/restart the qmgr; but will leave the applications in an unknown state.
_________________
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 |
|
|
| Vitor |
| Posted: Thu Apr 09, 2009 11:59 am Post subject: Re: endmqm & strmqm functionality |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Sam Uppu wrote: |
| the app doesn't want to kill and restart their app. |
What does the app team think the app will be doing while the queue manager is down if it keeps running? Read a book? Knit a sweater? Loop wildly until the queue manager comes back?
Enquire politely with the app team what their design solution is for the app to be closed for server maintenance & so forth. When they look at you blankly, trout them.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| WMBDEV1 |
| Posted: Thu Apr 09, 2009 1:40 pm Post subject: |
|
|
Sentinel
Joined: 05 Mar 2009
Posts: 888
Location: UK
|
| Not knowing much about the profile of the app (like does it just open one connection to the QM and reuse again and again or does it reconnect to the QM each time), i'd also check the connection is being closed properly. |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Thu Apr 09, 2009 1:43 pm Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
| WMBDEV1 wrote: |
| Not knowing much about the profile of the app (like does it just open one connection to the QM and reuse again and again or does it reconnect to the QM each time), i'd also check the connection is being closed properly. |
The app is using a connection and reusing it again and again. They are closing the app connections properly otherwise the number of connections will increase and I dont see that.
Thanks. |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Thu Apr 09, 2009 1:45 pm Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
| mqjeff wrote: |
MQGMO_FAIL_IF_QUIESCING.
There is no Wait on MQPut.
If they're using a wait time of 3000, then you should be able to specify endmqm normally and have it complete successfully after 3000 microseconds, assuming the app time has done the correct thing when they get the RC they'll get.
If they specify a Wait time of "unlimited", then your endmqm will *never* complete, UNLESS they specify MQGMO_FAIL_IF_QUIESCING. |
Jeff,
Thanks for your input. I checked with the app team and they are saying they are using MQGMO_FAIL_IF_QUIESCING in their openoptions of their Get and also wait time of 1 sec.
Not sure what to think of.
Thanks. |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Thu Apr 09, 2009 1:47 pm Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
| Code: |
Take a look at amqiclen. If you run that before you restart the QM, it should allow the QM to restart. We had this problem on Solaris with MDBs preventing the QM from coming up.
You'll find this post very interesting:
http://www.mqseries.net/phpBB2/viewtopic.php?t=12594&highlight=mdb |
I need to see whether amqiclen will help. This I didn't try yet.
I have the same questions what you had in the above link:
1. It seems weird that the QM had a problem starting back up. I would have thought processes still tied into a QM would have made it difficult to shut down. And if the QM was shutdown (it was), then how can any processess still be connected???
The link what you posted is exactly the issue what I am facing right now.
Thanks. |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Thu Apr 09, 2009 1:57 pm Post subject: Re: endmqm & strmqm functionality |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
| Vitor wrote: |
| Sam Uppu wrote: |
| the app doesn't want to kill and restart their app. |
What does the app team think the app will be doing while the queue manager is down if it keeps running? Read a book? Knit a sweater? Loop wildly until the queue manager comes back?
Enquire politely with the app team what their design solution is for the app to be closed for server maintenance & so forth. When they look at you blankly, trout them. |
The purpose of bringing down the QM without the app was to simulate the Queue manager crashing unexpectedly. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Apr 09, 2009 2:20 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
Process 29744 is still running.
Process 29763 is still running.
Process 29756 is still running.
Process 29752 is still running.
Process 29748 is still running.
Process 29760 is still running. |
What programs were associated with these PIDs? Were they your applications? MQ components? If so, which ones?
_________________
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 |
|
|
|
|
