| Author |
Message
|
| BigAl |
 Posted: Tue Apr 17, 2007 6:06 am Post subject: Does qm.disconnect() cause QM to go into quiescing state? |
 |
|
Newbie
Joined: 17 Apr 2007
Posts: 4
|
I am new to MQ programming and I am debugging a Java application that has one thread that does a GET on a queue with options to WAIT, and WAIT UNLIMITED, and FAIL IF QUIESCING. Another thread, when requested to do so by a user, attempts to shutdown the application by calling disconnect on the queue manager. According to docs, this seems to make sense. Am I reading this right, that calling disconnect attempts to close all the queues, which I can only guess puts the queue manager into the quiescing state which should cause the GET to fail?
So either I have misunderstood this quiescing thing, or something is not working as it should.
I read in another post here that the 'fail if quiescing' does not apply to MQClients, which is what I am dealing with, but changing to 'binding' did not alter the behavior.
Can anyone clarify this for me? |
|
| Back to top |
|
 |
| zpat |
| Posted: Tue Apr 17, 2007 6:16 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Fail if quiescing does work with clients.
Your explanation sounds wrong, even if it worked it would be extreme to quisce a queue manager just to stop your own application.
Disconnecting one handle won't drop other handles. If you attempt to disconnect another thread's active handle then who knows what might happen but it is not advisable to try this.
The solution is not to issue an unlimited get wait, but to issue a get wait for perhaps five minutes and when the application gets a MQRC 2033 (due to expiry of the interval with no available message), then check for a closedown condition in the application and if set then MQCLOSE and MQDISC otherwise repeat the MQGET with WAIT for another five minutes and so on.
This way you return control to the application every so often. In addition to this the application should respect the queue manager quiescing MQRC and other relevant return codes. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Tue Apr 17, 2007 6:43 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
qm.disconnect()
disconnects your app from the qm, it does not quiesce the qmgr itself!
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| BigAl |
| Posted: Tue Apr 17, 2007 6:50 am Post subject: |
|
|
Newbie
Joined: 17 Apr 2007
Posts: 4
|
| Michael Dag wrote: |
qm.disconnect()
disconnects your app from the qm, it does not quiesce the qmgr itself! |
Ah! Great information. So, is there a Java method I can call on the qmgr to quiesce it? Or, is there some other way to quiesce it? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Apr 17, 2007 6:50 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Well. qm.disconnect() disconnects the particular handle associated with the MQQueueManager object named qm.
As zpat says, it's not clear what that will do if the handle is currently in use for a GET with WAIT_UNLIMITED. At least not clear to me, or zpat. Maybe it says in the InfoCenter somewhere.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Apr 17, 2007 6:53 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| BigAl wrote: |
| Michael Dag wrote: |
qm.disconnect()
disconnects your app from the qm, it does not quiesce the qmgr itself! |
Ah! Great information. So, is there a Java method I can call on the qmgr to quiesce it? Or, is there some other way to quiesce it? |
There's the command line.... 
AFAIK you can't quiesce through PCF, but I wait to be corrected on that.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| BigAl |
| Posted: Tue Apr 17, 2007 6:59 am Post subject: |
|
|
Newbie
Joined: 17 Apr 2007
Posts: 4
|
| zpat wrote: |
| The solution is not to issue an unlimited get wait, but to issue a get wait for perhaps five minutes and when the application gets a MQRC 2033 (due to expiry of the interval with no available message), then check for a closedown condition in the application and if set then MQCLOSE and MQDISC otherwise repeat the MQGET with WAIT for another five minutes and so on. |
I agree, and I can get things to work nicely if I do that. However, I have been constrained (until I can convince the client otherwose) to doing the unlimited wait. I am getting close to said convincing as time goes on.
If I can't convince them to let me set the wait interval, my other 'workaround' is to post a 'dummy' message onto the queue in question. That works nicely too.
Thanks for taking the time to share your thoughts. It is much apprecitated.
Al |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Apr 17, 2007 7:00 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
A control message, with a proper Feedback code, is the usual way to end a get with WAIT_UNLIMITED.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| BigAl |
| Posted: Tue Apr 17, 2007 10:39 am Post subject: |
|
|
Newbie
Joined: 17 Apr 2007
Posts: 4
|
| jefflowrey wrote: |
| A control message, with a proper Feedback code, is the usual way to end a get with WAIT_UNLIMITED. |
Sweet! It works like a charm.
Thanks for your help!
- Al |
|
| Back to top |
|
|
|
|
