| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MQRC 2161 MQRC_Q_MGR_QUIESCING |
« View previous topic :: View next topic » |
| Author |
Message
|
| Boomn4x4 |
 Posted: Thu Nov 21, 2013 7:41 am Post subject: MQRC 2161 MQRC_Q_MGR_QUIESCING |
 |
|
Disciple
Joined: 28 Nov 2011
Posts: 172
|
What is the benefit of MQPMO_FAIL_IF_QUIESCING?
According to the documentation, the QPUT QGET can still complete if the QMGR is quiescing. Is there a risk of the message getting lost? Should I take that MQPMO parameter out and just let the API put messages on the queue if quiescing? What are the risks (if any) of doing so? |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Nov 21, 2013 7:59 am Post subject: Re: MQRC 2161 MQRC_Q_MGR_QUIESCING |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Boomn4x4 wrote: |
| What is the benefit of MQPMO_FAIL_IF_QUIESCING? |
It allows the administrator to quiesce the queue manager.
| Boomn4x4 wrote: |
| According to the documentation, the QPUT QGET can still complete if the QMGR is quiescing. |
The option MQPMO_FAIL_IF_QUIESCING doesn't pertain to a Get call but to a Put call.
| Boomn4x4 wrote: |
| Is there a risk of the message getting lost? |
No. The message is still in your application (because the put will fail with a 2161 reason code). You get to handle it anyway you want.
| Boomn4x4 wrote: |
| Should I take that MQPMO parameter out and just let the API put messages on the queue if quiescing? |
No.
| Boomn4x4 wrote: |
| What are the risks (if any) of doing so? |
You're reliant on the MQ admin knowing he needs to stop your application before he quiesces the queue manager. If the application doesn't close down & disconnect when the MQ admin asks it to, he will have no option but to do something more drastic to close it down. At this point there's a risk of message loss as the application is forceably disconnected from the queue manager, possibly in the middle of an operation.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Thu Nov 21, 2013 9:00 am Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
I agree with the Vitor's answer with the exception of
| Quote: |
Boomn4x4 wrote:
Should I take that MQPMO parameter out and just let the API put messages on the queue if quiescing?
No.
|
Which I would change to 'It depends'.
The key thing about MQRC 2161 MQRC_Q_MGR_QUIESCING is that when it is received by an application the application should do it's utmost to end and disconnect promptly. However, there is no crime in finishing off what you are doing. So, if the application was in the middle of responding to an application and trying to put the reply then I see no reason why it should not take out the parameter, re-issue the put and then end. If, however, the application is in the middle of something and it will take a long time to complete then 'yes' it should probably back-out the current transaction and end. Of course, even this is too simplistic and may depend on the application's HA characteristics. For example, if an application gets MQRC 2161 MQRC_Q_MGR_QUIESCING then the right thing to do might be to disconnect, then reconnect (possibly to an alternative Queue Manager) and then re-issue the MQPUT. The bottom line is that MQPMO_FAIL_IF_QUIESCING is an MQPUT option so that the application has the choice about what to do in this situation. If there was a blanket rule that no applications should put messages when the queue manager is quiescing then the option wouldn't exist.
As for losing messages when the Queue Manager is ended then the application should take precautions if that is a concern. The beauty of messaging is that it gives the application easy access to transactions and persistence so it is up to application to decide how recoverable it's data is.
Regards,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Nov 21, 2013 9:46 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Developers are responsible for catching any and all exceptions, and taking appropriate action.
The _FAIL_IF_QUIESCING option on MQI calls allows the app to discover that the queue-manager is being quiesced, and to end the application gracefully.
An application that chooses to continue continue processing may be cancelled by the sysadmin.
WMQ does not lose messages. Messages within transactions in-flight (in syncpoint) when the qmgr is terminated will be rolled back at qmgr restart.
_________________
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 |
|
|
|
|
|
| |
|
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
|
|
|
|
