| Author |
Message
|
| ivanachukapawn |
 Posted: Wed Apr 21, 2010 6:56 am Post subject: Type = every but messages still on Trigger Queue |
 |
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
| Windows 2000 QM. Queues with trigger set to Every have a depth of 1 or 2. The initiation queue is empty. The trigger monitor is running and is functioning correctly. This condition was caused by a previous incident today in which the server was at max cpu and triggering was suspended (runaway application had maxed the cpu. when stopped, the initiation queue emptied but some messages still remain on queues with type=every). I am assuming from documentation that the QM's trigger interval setting (99999999) is irrelevant since it is relevant only to trigger type=first. Is there a way to re-generate the trigger event? |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Wed Apr 21, 2010 7:39 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| ...the server was at max cpu and triggering was suspended ... |
Huh? triggering was suspended by what/whom?
The trigger interval is for missed trigger events. And, yes, it is for TRIGTYPE(FIRST); so your setting it to EVERY prevents MQ from recognizing the missed trigger event.
With EVERY, your application(s) should have been written with the understanding that at least one instance of the consuming app must always be running.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Wed Apr 21, 2010 7:48 am Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
| Apparently, Windows 2000 was responsible for suspending triggering - the cpu was maxed at 100% for several hours by a runaway process unrelated to MQ. I have already resigned myself to hunting down the execution scripts and starting the dequeueing processes manually to handle these queue depths - there are only 5 or 6 messages left on queues. PS the app process is designed to dequeue a message, process the data, and exit. |
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Wed Apr 21, 2010 7:58 am Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
| FYI. I was able to get trigger events for these messages by turning off triggering and then turning it back on. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Apr 21, 2010 8:39 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| You should make the development team aware that trigger(every) is not guaranteed. There are a number of circumstances where a) it can trigger twice, b) it can skip a trigger for a given message. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Apr 21, 2010 9:41 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| PS the app process is designed to dequeue a message, process the data, and exit. |
I'm guessing that you mean process the messages (plural)?
MQ apps should mqget and process a message, then mqget and process another, if another message exists. This is done with MQGET with WAIT and WAITINTERVAL.
If you app gets a single message, and then ends itself, the app must be reinstantiated for each successive message. Launching an application is labor-intensive - a waste of resources. If this is how your apps behave, it is a worst-practice. Waiting for another message uses near-zero resources.
[edit] You have my permission to smack the app developer.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Thu Apr 22, 2010 3:33 am Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
| Jeff, could you send me some links or paste some snippets which describe the triggering reliability vulnerability related to type=every? I would like to convert this place to type=first and then use triggerInterval to deal with the occasional glitches that occur. Bruce, I'll be after the developers to modify code to drain queues before exiting - then I will be able to reconfigure to type=first |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Apr 22, 2010 4:00 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Apr 22, 2010 5:20 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Search here for many, many discussions on triggering and EVERY.
EVERY will launch another concurrent instance of the consuming application.
Does your server platform have sufficient resources (cpu, RAM, I/O) to tolerate multiple instances of the consuming app? Mainframes usually have lots of spare horsepower to allow for concurrency; Win and UNIX platforms usually don't.
Your developers must consider the impacts of multiple consuming apps.
Will multiple consumers interfere with each other? For example, if it takes two messages to comprise a transaction, the 2nd instance of the consuming app will consume one or the other of the messagess.
Will multiple consumers backend activities (like database updates) encounter resource conflicts?
Whatever TRIGTYPE you set, it is a best-practice for a consuming app to do an MQGET with WAIT loop: consume a message, look to see if there is another message to consume, repeat.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| exerk |
| Posted: Thu Apr 22, 2010 2:18 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
And bear in mind that in certain circumstances even trigger first can act like trigger every, e.g. if your trigint is set too low.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Apr 22, 2010 7:09 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| ivanachukapawn wrote: |
| Bruce, I'll be after the developers to modify code to drain queues before exiting - then I will be able to reconfigure to type=first |
Actually, if you want to avoid problems like this ASAP, switch to Trigger First as it wil auto recover from apps that only get 1 message and end. When the q closes MQ will retrigger and while you will deal with a lot of overhead with all the trigger messages, at least the q will be processed.
There are ways you can end up with messages on a queue and no more trigger messages being generated. Trigger On First with a good Trigger Interval will auto recover, as long as new messages keep coming or if you reset the trigger from on to off to on just once.
With Every if you have a lot of messages backlogged on the queue, you will have to sit there and keep turning triggering off and on and off and on to get enough trigger messages to deal with the backlog if the apps don't MQGET Until 2033.
Of course if you have the rare scenario where you actually need Trigger On Every don't switch to On First, but then it becomes critical to have the apps change ASAP to read until 2033 AND to set up Q depth monitoring on the input queue to alert you to situations where you have a rolling backlog of messages.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
