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 » General Discussion » Recommended Wait Intervals

Post new topic  Reply to topic
 Recommended Wait Intervals « View previous topic :: View next topic » 
Author Message
ml_black
PostPosted: Wed Feb 25, 2004 6:21 am    Post subject: Recommended Wait Intervals Reply with quote

Novice

Joined: 09 Feb 2004
Posts: 20

Hi.

What do you recommend I set the Wait Interval to for a Get with Wait running on a continuous loop? At this time, we don't expect many messages in total, although we could get short periods during the day where messages come in one after the other at a higher volume.

I did see Jeff Lowry's recommendation for a 30-second interval if 10 messages/minute. I don't think we'd ever have such a high rate. We might have times where we'd get 1 per minute, and then long periods of no messages.

Thanks for your advice, and thank to everyone on this forum--it's been so helpful to me for learning MQ!
Back to top
View user's profile Send private message
EddieA
PostPosted: Wed Feb 25, 2004 6:49 am    Post subject: Reply with quote

Jedi

Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles

What language are you running this in. Unless it's (not the latest) JMS, why do you need to come out of the wait. Just code an indefinite wait, but ensure that you have the Fail if Quiescing set.

Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0
Back to top
View user's profile Send private message
ml_black
PostPosted: Wed Feb 25, 2004 7:00 am    Post subject: Reply with quote

Novice

Joined: 09 Feb 2004
Posts: 20

It's in Java. I was going on info in this post->
http://www.mqseries.net/phpBB2/viewtopic.php?t=13107

Also from browsing this forum it was my understanding that unlimited WAITs can be difficult to break out of.
Back to top
View user's profile Send private message
EddieA
PostPosted: Wed Feb 25, 2004 9:26 am    Post subject: Reply with quote

Jedi

Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles

Quote:
unlimited WAITs can be difficult to break out of

As long as the API supports Fail if Quiescing, then the only possible reason to code a 'polling' type application would be if either the application must do 'something' that is not dependent on a message arriving, or the method to tell the application to 'stop' requires the application to wake up, other than by sending it an "end now" message.

With the Fail option, the GET will be interrupted if someone tries to close the Queue Manager down.

Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0
Back to top
View user's profile Send private message
ml_black
PostPosted: Wed Feb 25, 2004 9:30 am    Post subject: Reply with quote

Novice

Joined: 09 Feb 2004
Posts: 20

OK, thanks. However, I'm still restricted to use a looping GET with WAIT because of the quick and dirty way in which we're going to monitor this process.

So, any suggestions on the Wait Interval?
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Wed Feb 25, 2004 10:06 am    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7722

What are you going to do when the WAIT ends? If you are simply just going to reissue the get, then there is no point in coding a short WAIT. Use Unlimited. But if you are going to need to do some other kinda of work after the get every 10 seconds, or 10 minutes or 10 hours, then code the WAIT to be 10 seconds, or 10 minutes or 10 hours.

This may mean your app may sit for hours doing "nothing", as it waits on the blocking Get with Wait. Is this OK? If yes, OK, if not, then maybe you should use Triggering On First with maybe a 30 second wait. When a message arrives the first thing in the morning, you will get triggered. As long as messages keep arriving every 30 seconds or less, your program will stay up. Otherwise it will shutdown, until the next message finnaly arrives.

If this starting up is a huge problem, maybe you got 100 DB connections to make each time, then you are better off leaving Triggering Off, and using an Unlimited Get with Wait.

Fail If Quiescing will allow the QM to shutdown.

To gracefully end your app in other cases, you can send a message to the queue where the MQMD_FORMAT = QUIT. Your app would need to be coded to always look for this type of message on every MQGET, and if it finds it, it knows that you want it to cleanly shutdown.

I never understood the people who use a GET With WAIT of 10 seconds, and then simply keep reissuing the GET every 10 seconds.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
EddieA
PostPosted: Wed Feb 25, 2004 10:44 am    Post subject: Reply with quote

Jedi

Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles

Quote:
I never understood the people who use a GET With WAIT of 10 seconds, and then simply keep reissuing the GET every 10 seconds.

Other than JMS where Fail if Quiescing is a vendor extension, which only became available in the 5.3 version.

Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0
Back to top
View user's profile Send private message
techno
PostPosted: Tue Mar 02, 2004 9:32 pm    Post subject: Reply with quote

Chevalier

Joined: 22 Jan 2003
Posts: 429

How do you set the option 'Fail If Quiescing' in JMS?
Back to top
View user's profile Send private message
EddieA
PostPosted: Wed Mar 03, 2004 6:00 am    Post subject: Reply with quote

Jedi

Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles

You start by opening the Java (5.3) manual.

Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0
Back to top
View user's profile Send private message
techno
PostPosted: Wed Mar 03, 2004 8:32 am    Post subject: Reply with quote

Chevalier

Joined: 22 Jan 2003
Posts: 429

I was not kidding.

We have listener concept in JMS. Where is the option to set it?
Back to top
View user's profile Send private message
techno
PostPosted: Wed Mar 03, 2004 8:57 am    Post subject: Reply with quote

Chevalier

Joined: 22 Jan 2003
Posts: 429

I see setFailIfQuiesce for ConnectionFactory.

Looks like default parameter value is JMSC.MQJMS_FIQ_YES.

So, if I do not call this method on ConnectionFactory, is this parameter set by default?

Thanks
Back to top
View user's profile Send private message
EddieA
PostPosted: Wed Mar 03, 2004 9:30 am    Post subject: Reply with quote

Jedi

Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles

Main Entry: de·fault
Pronunciation: di-'folt, dE-; 'dE-"folt
Function: noun
.
.
.
5 : a selection automatically used by a computer program in the absence of a choice made by the user

Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0
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 » General Discussion » Recommended Wait Intervals
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.