| Author |
Message
|
| mqjeff |
 Posted: Thu Apr 09, 2009 2:23 pm Post subject: Re: endmqm & strmqm functionality |
 |
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Sam Uppu wrote: |
| The purpose of bringing down the QM without the app was to simulate the Queue manager crashing unexpectedly. |
Even better! Tell the app team "you failed your test." |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Apr 09, 2009 2:29 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Sam Uppu wrote: |
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.
|
I think the app team should read the documentation again. They are either using FAIL_IF_QUIESCING in the get options (which is correct) or they're using it in the open options (which is correct but won't cause the get to end if the queue manager signals).
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Apr 09, 2009 2:36 pm Post subject: Re: endmqm & strmqm functionality |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Sam Uppu wrote: |
| The purpose of bringing down the QM without the app was to simulate the Queue manager crashing unexpectedly. |
Then our advice is pointless. If the queue manager crashes, it's not going to matter if the app team have coded F_IF_Q or not!
Well, not all our advice. The point about the trout is still valid. At some point after the endmqm -i the application should have noticed the non-zero completion and reason codes coming back from the MQGet calls, and responded. A traditonal piece of logic is:
Check to see if the MQGet returns 2033 - if so, consider waiting for another message. If not, suspect that something bad has happened and consider closing gracefully.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Thu Apr 09, 2009 2:56 pm Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
| bruce2359 wrote: |
| 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? |
All these PIDs are related to app and when I grep for them, I see the app id associated with it. |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Thu Apr 09, 2009 2:59 pm Post subject: Re: endmqm & strmqm functionality |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
| mqjeff wrote: |
| Sam Uppu wrote: |
| The purpose of bringing down the QM without the app was to simulate the Queue manager crashing unexpectedly. |
Even better! Tell the app team "you failed your test." |
 . I can tell them if I have the solution in my hands. |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Thu Apr 09, 2009 3:14 pm Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
How the amqiclen works if there are multiple QMgrs on the same physical server?.
I think amqiclen works for the resources on the server and not for the resources used by individual QMgr. Correct me if I am wrong.
If this is the case not sure how to clear the shared memory + semaphores used by individual QMgrs.
Thanks. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Apr 09, 2009 9:10 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20763
Location: LI,NY
|
check out : /opt/mqm/bin/amqiclen -xvm QMGRNAME
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Apr 10, 2009 1:01 am Post subject: Re: endmqm & strmqm functionality |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Sam Uppu wrote: |
| . I can tell them if I have the solution in my hands. |
Look down. The trout is the solution.
The solution is in the hands of the app team, not you. If their application won't close gracefully when the queue manager goes down, you've no option but to kill -9 them closed.
It's a design problem their end.
To quote a popular UK meerkat - "Simples".
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Apr 10, 2009 1:08 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Sam Uppu wrote: |
| Correct me if I am wrong. |
You're wrong. 
Be sure, before you go down this path, that you (and the WMQ admins that follow you) will be happy to clean up after this application every time the queue manager needs to be closed.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| WMBDEV1 |
| Posted: Fri Apr 10, 2009 1:12 am Post subject: |
|
|
Sentinel
Joined: 05 Mar 2009
Posts: 888
Location: UK
|
| Sam Uppu wrote: |
The app is using a connection and reusing it again and again.
|
So at what point in the process do they close the connection? Until it is closed i'm guessing the QM will keep waiting for it. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Apr 10, 2009 2:39 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| WMBDEV1 wrote: |
| Sam Uppu wrote: |
The app is using a connection and reusing it again and again.
|
So at what point in the process do they close the connection? Until it is closed i'm guessing the QM will keep waiting for it. |
They're not actually trying to close the connection at all. If they specify FAIL_IF_QUIESCING, the connection will close itself when you put in endmqm.
Then they will get back a return code that tells them that the qmgr is shutting down. Then they should go ahead and close any other connections they have, proactively, and then do whatever they are supposed to do if the qmgr crashes. This may be shut down entirely, it may be switch to using an alternate transport for data, or it may be to go into a long wait/retry cycle until the qmgr is back up. |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Fri Apr 10, 2009 4:30 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
| bruce2359 wrote: |
| 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. |
So, look at every MQI call and see if "FAIL_IF_QUIESCING" is an option and if it is used. When you find it is an option and not used, slap the app team members about with a trout liberally. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Apr 10, 2009 5:11 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9475
Location: US: west coast, almost. Otherwise, enroute.
|
If the purpose of the application design was to simulate the qmgr crashing unexpectedly AND keeping it from restarting, then the developers were successful. They deserve a trout and other forms of public humiliation for writing horrible code.
Was this test done in a test environment? Or was it in production?
If production, I'd be looking at terminating (firing) the developer(s) for deriliction of duty.
_________________
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 |
|
|
| Sam Uppu |
| Posted: Fri Apr 10, 2009 6:49 am Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
| bruce2359 wrote: |
If the purpose of the application design was to simulate the qmgr crashing unexpectedly AND keeping it from restarting, then the developers were successful. They deserve a trout and other forms of public humiliation for writing horrible code.
Was this test done in a test environment? Or was it in production?
If production, I'd be looking at terminating (firing) the developer(s) for deriliction of duty. |
This test was done in PROD as they dont really have any PROD traffic yet. They recently migrated to PROD. But the same code is deployed in all their environments, Dev through PROD. The same problem is happening in all of their environments. They have to fix in each and every environments and I need to direct them... You know what how?. I am not that good at Java to review their code.
Thanks. |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Fri Apr 10, 2009 6:59 am Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
| Vitor wrote: |
| Sam Uppu wrote: |
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.
|
I think the app team should read the documentation again. They are either using FAIL_IF_QUIESCING in the get options (which is correct) or they're using it in the open options (which is correct but won't cause the get to end if the queue manager signals). |
Vitor/ Jeff,
I like to see these 2 things:
1. openOptions
2. gmo.options
When I look into some of the code samples, I see the FAIL_IF_QUIESCING both in the openoptions and gm.options.
| Quote: |
// Set up the options on the queue we wish to open.
int openOptions =MQC.MQOO_INPUT_SHARED + MQC.MQOO_FAIL_IF_QUIESCING; |
| Quote: |
// Set the get message options.
MQGetMessageOptions gmo = new MQGetMessageOptions();
gmo.options =
gmo.options + MQC.MQGMO_WAIT + MQC.MQGMO_FAIL_IF_QUIESCING;
gmo.matchOptions = MQC.MQMO_NONE;
gmo.waitInterval = MQC.MQWI_UNLIMITED; |
Can you guys let me know which one I have to go with?. Or else, I need to have in both places?.
Thanks. |
|
| Back to top |
|
|
|
|
