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 IBM MQ Support » Triggering on First

Post new topic  Reply to topic
 Triggering on First « View previous topic :: View next topic » 
Author Message
girish_tharwani
PostPosted: Thu Aug 15, 2002 7:24 am    Post subject: Triggering on First Reply with quote

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
View user's profile Send private message
bduncan
PostPosted: Thu Aug 15, 2002 7:58 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website AIM Address
girish_tharwani
PostPosted: Thu Aug 15, 2002 8:38 am    Post subject: Reply with quote

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
View user's profile Send private message
mrlinux
PostPosted: Thu Aug 15, 2002 11:35 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
girish_tharwani
PostPosted: Thu Aug 15, 2002 11:42 am    Post subject: Reply with quote

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
View user's profile Send private message
PeterPotkay
PostPosted: Thu Aug 15, 2002 6:50 pm    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7716

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
View user's profile Send private message
mgrabinski
PostPosted: Thu Aug 15, 2002 9:10 pm    Post subject: Reply with quote

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
View user's profile Send private message
oz1ccg
PostPosted: Fri Aug 16, 2002 1:42 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail Visit poster's website MSN Messenger
girish_tharwani
PostPosted: Fri Aug 16, 2002 5:18 am    Post subject: Reply with quote

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
View user's profile Send private message
PeterPotkay
PostPosted: Fri Aug 16, 2002 5:21 am    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7716

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
View user's profile Send private message
girish_tharwani
PostPosted: Fri Aug 16, 2002 6:20 am    Post subject: Reply with quote

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
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 IBM MQ Support » Triggering on First
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.