Author |
Message
|
ml_black |
Posted: Wed Feb 25, 2004 6:21 am Post subject: Recommended Wait Intervals |
|
|
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 |
|
 |
EddieA |
Posted: Wed Feb 25, 2004 6:49 am Post subject: |
|
|
 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 |
|
 |
ml_black |
Posted: Wed Feb 25, 2004 7:00 am Post subject: |
|
|
Novice
Joined: 09 Feb 2004 Posts: 20
|
|
Back to top |
|
 |
EddieA |
Posted: Wed Feb 25, 2004 9:26 am Post subject: |
|
|
 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 |
|
 |
ml_black |
Posted: Wed Feb 25, 2004 9:30 am Post subject: |
|
|
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 |
|
 |
PeterPotkay |
Posted: Wed Feb 25, 2004 10:06 am Post subject: |
|
|
 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 |
|
 |
EddieA |
Posted: Wed Feb 25, 2004 10:44 am Post subject: |
|
|
 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 |
|
 |
techno |
Posted: Tue Mar 02, 2004 9:32 pm Post subject: |
|
|
Chevalier
Joined: 22 Jan 2003 Posts: 429
|
How do you set the option 'Fail If Quiescing' in JMS? |
|
Back to top |
|
 |
EddieA |
Posted: Wed Mar 03, 2004 6:00 am Post subject: |
|
|
 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 |
|
 |
techno |
Posted: Wed Mar 03, 2004 8:32 am Post subject: |
|
|
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 |
|
 |
techno |
Posted: Wed Mar 03, 2004 8:57 am Post subject: |
|
|
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 |
|
 |
EddieA |
Posted: Wed Mar 03, 2004 9:30 am Post subject: |
|
|
 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 |
|
 |
|