| Author |
Message
|
| geoffbland |
 Posted: Wed May 09, 2007 9:23 am Post subject: MQGMO_FAIL_IF_QUIESCING & MQGMO_NO_WAIT Options |
 |
|
Newbie
Joined: 09 May 2007
Posts: 5
|
What affect (if any) does the MQGMO_FAIL_IF_QUIESCING option have if I'm using MQGMO_NO_WAIT?
The docs tend to suggest that MQGMO_FAIL_IF_QUIESCING is only relevant if we're doing a MQGMO_WAIT (or waiting on a signal).
But I have an "MQ guy" here that is saying that MQGMO_FAIL_IF_QUIESCING should always be specified.
Thanks for your help. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed May 09, 2007 10:35 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
You should still code FAIL_IF_Qetc so that when your application does a get (without, as you say, waiting) the get can signal your application to close because the queue manager is coming down.
Less important if you have some other means of closing your application perhaps, but it's still good form. Consider the hapless MQadmin, facing a problem and needing to close down. If he doesn't know how to closedown your application, or in the white heat of the moment it slips his mind, he could be forced to drastic means to bring the queue manager down.
If, however, the application correctly responds to the quiecse signal (perhaps protesting "I was expecting a stop message" into the log as it goes) then everyone's a winner.
My 2 cents, other views may be equally valid. But for the cost of specifying an option that won't cause any processing issues, why not specify it?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| geoffbland |
| Posted: Wed May 09, 2007 11:07 pm Post subject: |
|
|
Newbie
Joined: 09 May 2007
Posts: 5
|
Many thanks for that answer; I just want to ensure I understand this correctly.
Obviously my app handles shut down and polling itself, but if I do specify MQGMO_FAIL_IF_QUIESCING and MQGMO_NO_WAIT is it certain that I will get a recognisable exception when the QMgr is "quiesed" rather than just the normal MQCC_FAILED & MQRC_NO_MSG_AVAILABLE?
A more rhetorical question now; if you should always specify MQGMO_FAIL_IF_QUIESCING no matter how you use the queues, why is this an option?
Finally (sorry about all the extra questions), the MQ Book "Application Programming Reference" states on Windows 32/64 the MQGMO_FAIL_IF_QUIESCING option is ignored. Does that mean it is turned on or off by default? (Our "MQ Guy" says that I should ignore the reference book as it doesn't apply to Java apps???) |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu May 10, 2007 12:47 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| geoffbland wrote: |
Obviously my app handles shut down and polling itself, but if I do specify MQGMO_FAIL_IF_QUIESCING and MQGMO_NO_WAIT is it certain that I will get a recognisable exception when the QMgr is "quiesed" rather than just the normal MQCC_FAILED & MQRC_NO_MSG_AVAILABLE?
|
If this option is specified, you'll receive an MQRC_Q_MGR_QUIESCING instead of MQRC_NO_MSG_AVAILABLE.
| geoffbland wrote: |
A more rhetorical question now; if you should always specify MQGMO_FAIL_IF_QUIESCING no matter how you use the queues, why is this an option?
|
For the same reason MQPMO_NEW_MSG_ID is an option. You should always get the queue manager to generate a new id, and you should always close when the queue manager tells you. There are rare, strange and exceptional circumstances and MQ caters for those by making them options.
An analogy I often use is that my car can travel at 100mph. I can think of no circumstances when I'd want to drive it that fast & if I did it wouldn't be a good idea (or safe!) for a number of reasons, but the functionality has been fitted to the car and in rare, strange and exceptional circumstances I might use it. No such circumstance immediately comes to mind however...
| geoffbland wrote: |
Finally (sorry about all the extra questions), the MQ Book "Application Programming Reference" states on Windows 32/64 the MQGMO_FAIL_IF_QUIESCING option is ignored. Does that mean it is turned on or off by default? (Our "MQ Guy" says that I should ignore the reference book as it doesn't apply to Java apps???) |
It doesn't apply to Windows apps either, and that quote is not immediately visable in my copy of the reference manual!!! Please provide the SC and page number where you're seeing this! 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bob_buxton |
| Posted: Thu May 10, 2007 2:27 am Post subject: |
|
|
Master
Joined: 23 Aug 2001
Posts: 266
Location: England
|
| geoffbland wrote: |
A more rhetorical question now; if you should always specify MQGMO_FAIL_IF_QUIESCING no matter how you use the queues, why is this an option? |
If your application is processing a message group or other related set of messages it probably makes sense for your application to complete processing the current batch of messages before it terminates.
In this type of application you would only use Fail-if-quiescing when attempting to get the first message of a batch.
In retrospect it might have been better to have had an Allow-if-quiescing option and made failure the default behaviour but it is far to late and too disruptive to change defaults now.
_________________
Bob Buxton
Ex-Websphere MQ Development |
|
| Back to top |
|
|
| geoffbland |
| Posted: Thu May 10, 2007 2:32 am Post subject: |
|
|
Newbie
Joined: 09 May 2007
Posts: 5
|
Many thanks for that - very useful.
The doc looks like an MQ 5.1 version doc, it says it is "Sixth Edition (January 1999)". The quote is at the top of page 81. It's entitled "Application Programing Reference".
The application was originally written against 5.1 but is now using 6.0 (6.0.2). |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu May 10, 2007 2:36 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| geoffbland wrote: |
| The doc looks like an MQ 5.1 version doc, |
v5.1? Keep hold of it, the British Library will probably want it for their collection..... 
A lot of water's flowed under the bridge since v5.1 was the current version. I'd get the current docs from the IBM website, or use the online infocentre.
(Personally, I like the PDFs but that's just me). 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
