| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Trigger Interval |
View previous topic :: View next topic |
| Author |
Message
|
| MarkDev |
 Posted: Thu Jan 08, 2004 1:21 pm Post subject: Trigger Interval |
 |
|
Newbie
Joined: 28 Jul 2003
Posts: 8
|
| In a trigger first scenario, if a triggered application dies and the message is not pulled from the queue and the trigger interval passes, any new messages will trigger. What happens to the previous messages? |
|
| Back to top |
|
 |
| mrlinux |
| Posted: Thu Jan 08, 2004 1:28 pm Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
Well if the trigger interval passes it will generate a new trigger message and your app should read the queue till empty.
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| MarkDev |
| Posted: Fri Jan 09, 2004 8:36 am Post subject: |
|
|
Newbie
Joined: 28 Jul 2003
Posts: 8
|
| What currently happens is any messages that were "stuck" in the queue are no longer there and do not show up in the DLQ. I was just wondering if those messages get permanently removed when the trigger interval passes and a new message is put. |
|
| Back to top |
|
|
| mrlinux |
| Posted: Fri Jan 09, 2004 8:59 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
No the only way messages are removed from a queue are
1) Application gets the message (Successfully)
2) Message Expires. Application sets expiry time in mqmd.
3) If message is non-persistend and qmgr is restarted
As for your description it sounds like you app is reading the message off the queue before it dies
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| oz1ccg |
| Posted: Sat Jan 10, 2004 1:37 am Post subject: |
|
|
Yatiri
Joined: 10 Feb 2002
Posts: 628
Location: Denmark
|
Hmm, this was also the TRIGINT behavior I first thought of before I studiet the manual  , but it seems to wok in this way:
You will get addional triggers generated when messages are put to the queue after the TRIGINT have expired, but only when the queue is not opend for INPUT, this means that no application have the queue opend for reading.
This also requires that the applications are well coded; I mean that the application itself have to issue MQCLOSE, and not trust some OS-termination routine to do the job, (because it may take a while before the OS does this, this is a low prio. job).
I'm typicly using TRIGINT(60000) on my queuemanagers as default (not changed), and I've never seen problems with well-degigned applications 
Some snips from Application Programming Guide:
| Quote: |
Trigger condition 4:
For triggering of type FIRST or DEPTH, no program has the application queue open for removing messages (that is, the OpenInputCount local queue attribute is zero).
Special case of trigger type FIRST
With trigger type FIRST, if there is already a message on the application queue when another message arrives, the queue manager does not usually create another trigger message. However, the application serving the queue might not actually open the queue (for example, the application might end, possibly because of a system problem). If an incorrect application name has been put into the process definition object, the application serving the queue will not pick up any of the
messages. In these situations, if another message arrives on the application queue, there is no server running to process this message (and any other messages on the queue).
To deal with this, the queue manager creates another trigger message if another message arrives on the application queue, but only if a predefined time interval has elapsed since the queue manager created the last trigger message for that queue. This time interval is defined in the queue manager attribute TriggerInterval. Its default value is 999 999 999 milliseconds.
You should consider the following points when deciding on a value for the trigger interval to be used in your application:
- If TriggerInterval is set to a low value, and there is no application serving the application queue, trigger type FIRST might behave like trigger type EVERY (this depends on the rate that messages are being put onto the application queue, which in turn may depend on other system activity). This is because, if the trigger interval is very small, another trigger message is generated each time a message is put onto the application queue, even though the trigger type is FIRST, not EVERY. (Trigger type FIRST with a trigger interval of zero is equivalent to trigger type EVERY.)
- If a unit of work is backed out (see “Trigger messages and units of work”) and the trigger interval has been set to a high value (or the default value), one trigger message is generated when the unit of work is backed out. However, if you have set the trigger interval to a low value or to zero (causing trigger type FIRST to behave like trigger type EVERY) many trigger messages can be generated. If the unit of work is backed out, all the trigger messages are still made available. The number of trigger messages generated depends on the trigger interval, the maximum number being reached when trigger interval has
been set to zero. |
Just my $0.02 
_________________
Regards, Jørgen
Home of BlockIP2, the last free MQ Security exit ver. 3.00
Cert. on WMQ, WBIMB, SWIFT. |
|
| 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
|
|
|
|
