ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » IBM MQ API Support » Quiescing

Post new topic  Reply to topic
 Quiescing « View previous topic :: View next topic » 
Author Message
patrick flaherty
PostPosted: Mon Apr 10, 2006 1:09 pm    Post subject: Quiescing Reply with quote

Novice

Joined: 27 Mar 2006
Posts: 14
Location: SF E Bay

Hi,

We had (for the first time) a server/listener up running over the wkend. It failed Sunday morning.

With message #2202. Which turns out to be MQRC_CONNECTION_QUIESCING.

Looked in my code (which I'd mostly copied off of various MQS-related Internet sites). This would seem pretty obvious:

Code:

MQOPEN (connection_handle, &object_descriptor, MQOO_INPUT_AS_Q_DEF+MQOO_FAIL_IF_QUIESCING, &object_handle, &CompCode, &Reason);


So to fix the problem is it just a matter of removing the MQOO_FAIL_IF_QUIESCING option?

But what is Quiescing in the first place? And the code above that I'd copied, represented itself as pretty much 'default' code. So why (if so) would FAIL_IF_QUIESCING be the norm?

thanx.

pat
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Mon Apr 10, 2006 1:16 pm    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY

Well were you in the process of stopping the channel?
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
patrick flaherty
PostPosted: Mon Apr 10, 2006 1:27 pm    Post subject: Reply with quote

Novice

Joined: 27 Mar 2006
Posts: 14
Location: SF E Bay

From what systems, and others who can touch the MQS server machine, tell me is that they weren't doing anything.

pat
Back to top
View user's profile Send private message
patrick flaherty
PostPosted: Mon Apr 10, 2006 1:33 pm    Post subject: Reply with quote

Novice

Joined: 27 Mar 2006
Posts: 14
Location: SF E Bay

Ah. The time stamp was this morning - not Sunday.

So it was me (mea culpa).

I wanted to post a message from the Windows side without the listener (VMS [on the same Q of course]) scopping it up immediately.

(on the advice of another programmer) I right-clicking on the Channel; Stop dialog; box at the bottom = inactive.

Is there some way of 'pausing' a Q such that others applications attached to it won't die?

pat
Back to top
View user's profile Send private message
mvic
PostPosted: Mon Apr 10, 2006 1:43 pm    Post subject: Reply with quote

Jedi

Joined: 09 Mar 2004
Posts: 2080

patrick flaherty wrote:
Is there some way of 'pausing' a Q such that others applications attached to it won't die?

I think the point here is that you (or someone) had said "endmqm qmgrname". When an administrator says that, the queue manager will quiesce and will end as soon as it is able to do so according to the rules outlined in the docs.

Sorry if I missed the point.
Back to top
View user's profile Send private message
kevinf2349
PostPosted: Mon Apr 10, 2006 3:27 pm    Post subject: Reply with quote

Grand Master

Joined: 28 Feb 2003
Posts: 1311
Location: USA

Quote:
So why (if so) would FAIL_IF_QUIESCING be the norm?


It is the norm for all 'well-behaving' applications because if someone wants to stop the queue manager then the chances are they want to do it quickly. If an application detects the 'quiescing' condition then it should (if the business logic allows) get the heck out of MQ as quickly and cleanly as possible. This is particulary the case for long-running MQ enabled applications.

If they don't then the queue manager will remain up until the last application terminates. It is easier if the application detects the condition and gets out of there, than it is to manual find them and close them out.

If the application is written nicely it may even not stop, just as long as it stops its MQ activity (ie Disconnects). It could then keep on retrying the connect again every minute or so until the queue manager is back up.

Hope this helps
Back to top
View user's profile Send private message
patrick flaherty
PostPosted: Tue Apr 11, 2006 8:24 am    Post subject: Reply with quote

Novice

Joined: 27 Mar 2006
Posts: 14
Location: SF E Bay

Thanx.

But is there any way to actually pause a Q? That is, stop it from forwarding on messages (or accpeting I suppose). But nothing attached to it drops/dies/etc?

This is so the that I can inspect the contents of the current messages on the Q. This is in a development environment (as I'm rolling out a system and checking one thing after another along the way).

pat
Back to top
View user's profile Send private message
Vitor
PostPosted: Tue Apr 11, 2006 8:34 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

patrick flaherty wrote:
Thanx.

But is there any way to actually pause a Q? That is, stop it from forwarding on messages (or accpeting I suppose). But nothing attached to it drops/dies/etc?

This is so the that I can inspect the contents of the current messages on the Q. This is in a development environment (as I'm rolling out a system and checking one thing after another along the way).

pat


A queue doesn't forward messages; the movement of messages is controlled by the applications attached to it. It's possible to stop the placing of new messages on the queue or the removal of messages by inhibiting gets/puts but this will result in return codes and the probable termination of these applications.

The question's how the application reacts. As kevinf2349 correctly points out, polite applications don't draw attention to the foibles of the infrastructure. They cough discretely, and then retry the failing opperation. Armed with this sort of logic you can "pause" a queue by inhibiting it, examine the contents and then reenable the queue with no harm done.

Of course, if it's a development environment the same effect can be achieved by stopping and starting the applications when you want to check the queues. Fewer code changes as well, though IMHO graceful handling of errors is not a bad thing to build into prod code.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » IBM MQ API Support » Quiescing
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.