Author |
Message
|
girish_tharwani |
Posted: Thu Aug 15, 2002 7:24 am Post subject: Triggering on First |
|
|
 Voyager
Joined: 01 Aug 2001 Posts: 88 Location: Pune, India
|
I have a very basic question on triggering.
I put a message on a local queue that is set for Trigger type First. A trigger message is generated and put on Initiation queue thus an application is trigger. I believe the trigger message is gone from Init queue at this time.
The triggered application that is supposed to consume the message from local queue dies down due to some uncontrolled error and the message is not consumed.
My question is that will this application be triggered again even if no new messages arrive on local queue (and even if the trigger type is first)?
Why and How ? When ? is it somehow related to the TriggerInterval attribute of Queue manager. |
|
Back to top |
|
 |
bduncan |
Posted: Thu Aug 15, 2002 7:58 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001 Posts: 1554 Location: Silicon Valley
|
Yes... Use the search link on this site and look for "trigger interval". You should find quite a few discussions explaining it. _________________ Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
Back to top |
|
 |
girish_tharwani |
Posted: Thu Aug 15, 2002 8:38 am Post subject: |
|
|
 Voyager
Joined: 01 Aug 2001 Posts: 88 Location: Pune, India
|
I read the old discussions as well as the MQ series documentation and as I understand:
Application can be trigger in case of Trigger type First on the arrival of new message (even if queue depth was not zero previously) if the last trigger message was generated TriggerInterval seconds ago.
Application can be triggered again, if the application reads the message, backs out it and close the queue. In this case application has to make the decision on the basis of BackoutCound when it is triggered second time
But my situation is a third situation in which the application opens the queue, does some operations (say some logging, some DB work etc) and then reads the queue. Now even if I put only one message on the queue and some operation failes after opening the queue but before reading the queue and causes the applicaiton to fail, OpenInputCount of local queue goes back to zero and that causes the application to be triggered again. Before someone can attend the problem, within a matter of minutes, this application is triggerd and abended thousands of times causing that many error notifications. How do I stop this repetative triggering ? Is there any method other than making an MQSET call from the application itself to turn the trigger off ? |
|
Back to top |
|
 |
mrlinux |
Posted: Thu Aug 15, 2002 11:35 am Post subject: |
|
|
 Grand Master
Joined: 14 Feb 2002 Posts: 1261 Location: Detroit,MI USA
|
Well first of all the the trigger is generated when the CURRENT Depth of a queue goes from 0 to 1, (not the OpenInputCount ) with exceptions
1) If the messages is read from the queue under syncpoint and the message is rolled back it can generate another trigger.
2) There is a qmgr attribute called TRIGGER INTERVAL and that will
can be used to prevent excessive re-triggering. _________________ Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
Back to top |
|
 |
girish_tharwani |
Posted: Thu Aug 15, 2002 11:42 am Post subject: |
|
|
 Voyager
Joined: 01 Aug 2001 Posts: 88 Location: Pune, India
|
Well its confusing matter.
My observations are based on
MQSeries Manuals / MQSeries Application Programming Guide / Part 2 / Chapter 14 / Conditions for a trigger event
Please check out the point number 11 and 12 in this document. As per these there are some more exception conditions |
|
Back to top |
|
 |
PeterPotkay |
Posted: Thu Aug 15, 2002 6:50 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
If an app closes a queue that is triggered on first (IPROCS go to zero), and there are more than zero messages on that queue, the QM will generate another trigger message to the init queue. That trigger message will sit in the trigger queue until the app ends, at which point the app gets restarted beacause the trigger message was used by the trigger monitor.
So if your app is doing this code:
MQCONN
MQOPEN
MQCLOSE
MQDISC
and there is more than zero messages on the queue, you got it, an endless loop of triggers.
TriggerInterval will not help here. It only helps the situation where you have a closed queue and already more than 1 message on the queue as more arrive.
There is no way in MQ to stop this behaviour, short of changing the trigger to off.
But my question to you is this: What in the world is your app doing in between the open and the get? It should be nothing! Get whatever buggy code is in there and move it in front of the open or after the get. If you do this, now you got options if things go wrong.
If you open the queue, you do the get. If the code fails after the get and the message gets rolled back, now the backout count will be incremented. Any app that gets triggered and gets under syncpoint should always check the backoutcount of the message immediatly after the get, and handle the bad ones appropriatly to prevent the endless loop.
What if the get fails and the message is not returned? Well, for some GET fails you can fix the problem in the program and try again (like truncated messages and increasing the buffer). For all the other errors, you are no better off. Back to the endless loop. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
mgrabinski |
Posted: Thu Aug 15, 2002 9:10 pm Post subject: |
|
|
Master
Joined: 16 Oct 2001 Posts: 246 Location: Katowice, Poland
|
I had similiar situation on OS/390. A CICS transaction was triggered, got a message, but was rollbacked so the message got back to the queue and caused another trigger. Endless loop.
There is a very useful MQGET option - MQGMO-MARK-SKIP-BACKOUT (only on OS/390) that allows the exclude a poisonous message from the unit of work. _________________ Marcin Grabinski <>< |
|
Back to top |
|
 |
oz1ccg |
Posted: Fri Aug 16, 2002 1:42 am Post subject: |
|
|
 Yatiri
Joined: 10 Feb 2002 Posts: 628 Location: Denmark
|
I've been working with OS/390 CICS and MQSeries, what we normally do is if the application discover a problem, report it and then wait for some time with the queue open (to prevent retriggering) and then terminate.
This normally will keep it up, and in case of errors and bad designed programs this will work. If the program is well designed, it checks BACKOUTCOUNT, and move bad messages to a Backout Queue for later investigations/processing.
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 |
|
 |
girish_tharwani |
Posted: Fri Aug 16, 2002 5:18 am Post subject: |
|
|
 Voyager
Joined: 01 Aug 2001 Posts: 88 Location: Pune, India
|
PeterPotkay wrote: |
But my question to you is this: What in the world is your app doing in between the open and the get? It should be nothing! Get whatever buggy code is in there and move it in front of the open or after the get. If you do this, now you got options if things go wrong. |
Exactly the same direction I was taking. I am putting OPEN and GET call together and I can check the backout count. But what happens if the app failes after connecting to queue manager but before opening the queue (now dont ask what I am doing between these two calls ). What will be the trigger behaviour in this case. Will I get another trigger ? I am trying to put together some experiment on this but if you know the answer, let me know. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Fri Aug 16, 2002 5:21 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
If you never open the queue, then you never close it, so you don't get retriggered.
If more messages arrive after the TriggerInterval passes you will get retriggered.
If no more message arrive, you will have a queue with 1 message, and an app that will not be started unless you intervine. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
girish_tharwani |
Posted: Fri Aug 16, 2002 6:20 am Post subject: |
|
|
 Voyager
Joined: 01 Aug 2001 Posts: 88 Location: Pune, India
|
All questions answered. Thanks, Thanks a lot. I am implementing it. If I get any confilcting results, I will report back.  |
|
Back to top |
|
 |
|