| Author |
Message
|
| mikegrove |
 Posted: Mon Jul 02, 2007 10:44 am Post subject: TriggerInterval |
 |
|
Novice
Joined: 02 Jul 2007
Posts: 11
|
I have read the APG but came away confused. I am new to MQ and am dealing with a application that is kicked off by a trigger, misbehaving. The trigger is a 'First' type.
I read this:
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.
I read the linked article also but am still confused. If a message is backed out either on the 'put' or the 'get', does the trigger fire again?
Also where do you set the TriggerInterval and can it launch a different program than the 'First' trigger?
Thanks for any insight
Mike |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Mon Jul 02, 2007 10:49 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
An application that is properly using trigtype(first) should be reading the queue until it receives a 2033.
A message that is backed out will be returned by the very next get that can retrieve that message.
Thus backing out a message will cause the next get to NOT return a 2033.
Ergo, no need for a new trigger...
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| mikegrove |
| Posted: Mon Jul 02, 2007 11:00 am Post subject: |
|
|
Novice
Joined: 02 Jul 2007
Posts: 11
|
The app that is getting the messages, goes until no more messages, then waits 30 seconds. I did not put any code to check for single instance, my bad, I didn't think it could happen using triggers to start it. I am putting that code in now, but I don't understand how the program could have more than one instance running at a time, which it invariably does, when it hangs.
Are there any circumstances wher the trigger could fire more than once before all messages are off the queue?
Mike |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Jul 02, 2007 11:07 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
what does it mean "and then waits 30 seconds"? Does that mean you're doing the equivalent of a sleep(30)? Or are you doing another Get with a 30 second wait?
If you're doing the sleep... then your app is still open, but presumably the queue is closed. Then another message comes in, and triggers another instance of the program.
Otherwise, generally, no. There should only be a trigger generated on a trigtype(first) queue when the qdepth goes from 0 to 1 - and uncommited messages (available for rollback) don't get removed from qdepth.
Edit: Well, unless the trigint is set low, or the app "freezes" for a long time. TRIGINT is set on the qmgr.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| mikegrove |
| Posted: Mon Jul 02, 2007 11:35 am Post subject: |
|
|
Novice
Joined: 02 Jul 2007
Posts: 11
|
I have the wait_interval set to 30 seconds. My understanding is that my app will block for 30 seconds or until another msg shows up, whichever comes first. After 30 seconds of no msg my app exits the get loop and the app itself shuts down.
What if a 'Put' is rolled back and not committed? does it affect the queue depth, or only if the commit is made? My understanding is that my wait_interval must take into account the longest time it would take for the commit to happen after the initial put.
Does this apply only to puts:
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. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Jul 02, 2007 11:44 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
A message that has been put under syncpoint can cause qdepth to increase before it is committed - IIRC. This could cause a "false" trigger. In the case of your application, it should start up, open the queue, issue the get with WAIT. If the message is not committed in that 30 second wait... then your app will end normally. If the message IS committed, then your app will get it.
In either case, during that interval, the qdepth is >0 and the triggered queue is open for input - so no new trigger.
In general, the things to do to solve/understand trigger problems is to a) re-read the trigger conditions and go through them one by one and analyze your situation to see if they match, b) restart the trigger monitor in the foreground or in such a way to log the output...
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| mikegrove |
| Posted: Mon Jul 02, 2007 12:00 pm Post subject: |
|
|
Novice
Joined: 02 Jul 2007
Posts: 11
|
Is there any way to see what process or how many have a queue open.
In other words can I see if MQ thinks my app still has the queue open and in the case of multiple instances, how many it thinks have a connection?
How do I start the trigger monitor to log its info? Is there already a log I can look at?
Thanks for all the help. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Jul 02, 2007 12:06 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
The default trigger monitor logs to stdout.
Most people run the default trigger monitor in a way that stdout doesn't get captured anywhere...
Yes, you can see what processes or how many have a queue open. OPPROCS and IPPROCS from dis q(..) will show you how many have a queue open for OutPut and InPut respectively. Dis qstatus(...) will, with the right options, show you the connections to a queue. dis conn(...) will show you info on a given connection.
Or the MQ Explorer makes this somewhat easier.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| mikegrove |
| Posted: Mon Jul 02, 2007 12:09 pm Post subject: |
|
|
Novice
Joined: 02 Jul 2007
Posts: 11
|
Thanks,
At least I'm not just throwing darts at the wall now.
Lot's of good info. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Jul 02, 2007 5:44 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| jefflowrey wrote: |
| A message that has been put under syncpoint can cause qdepth to increase before it is committed - IIRC. This could cause a "false" trigger. |
The trigger message will not be generated for an MQPUT under syncpoint UNTIL the message is either commited, OR backed out. Committed, your app is triggered and will find the message normally. If backed out, your app is triggered and finds an empty q, thus the reason it needs to be able to handle a 2033.
Why is the trigger message generated when the MQPUT is backed out? Message #1 under syncpoint is put on the q and changes the depth from 0 to 1. Because the message is not commited, there is no sense to create a trigger message yet. BUT if Message #1 is on the queue uncommitted, 1 or more other message can land on the queue. Those additional messages are not changing the q depth from 0 to 1 (message #1 did that). When message #1 is backed out, if the trigger message was also, your app would not get triggered (messages #2 and above did not satisfy all the trigger conditions) and thus your triggered q would find itself with more than zero message and no trigger.
Producing that trigger message when an MQPUT is backed out protects against this scenario.
Mike,
Trigger Interval has nothing to do with this. It does protect against the scenario where a trigger on first queue has more than 0 messages and the previous trigger message was not successful in starting the app and getting the app to run to the point where it was able to open the queue.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Nigelg |
| Posted: Mon Jul 02, 2007 9:55 pm Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
| Quote: |
| The trigger message will not be generated for an MQPUT under syncpoint UNTIL the message is either commited, OR backed out. |
A trigger msg is generated when the msg is put, not when it is committed. However, the trigger msg is put in the same unit of work as the original msg, so it is not available to the trigger monitor until the commit.
BTW
This will cause a false queue service event to be generated if the UoW is held open for longer than the event interval. The app will not trigger until the trigger msg is committed, and so the msg will not be retrieved until after the interval has expired.
No trigger msg is generated on rollback; anyway, it would not make much sense to generate a trigger msg when an MQPUT is backed out, would it?
A trigger msg is not generated when an MQGET is backed out either.
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Jul 03, 2007 7:29 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Nigel,
You are correct about when the trigger message is genereated. Its right when the MQPUT happens. Thanks for catching that.
But the trigger message is committed (and thus finally available to the trigger monitor) whether the applications MQPUT is committed OR backed out. See #10 in the APG for Trigger Conditions. See my explanation up above why this is needed.
Also, see #12.b for the scenario where the getting app backs out its MQGET. That causes a trigger message to be generated.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Nigelg |
| Posted: Tue Jul 03, 2007 8:07 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
Pegter, thanks for putting me right on these, I thought I knew the triggering conditions.
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
|
|
