| Author |
Message
|
| Manishkj |
 Posted: Wed Dec 19, 2001 5:55 am Post subject: |
 |
|
Newbie
Joined: 11 Nov 2001
Posts: 9
|
Hi,
We are using triggering.
Most of the time it works fine but in some situation, triggering does not happen. Even if all the condition of triggering are satisfied. To resolve this problem we just restart the trigger monitor and now the triggering happens.
Has anybody else is facing this problem. What is the cause and resoulution of this problem.
Environment AIX 4.3.2
Mq version 5.0
Thanks in advance. |
|
| Back to top |
|
 |
| kolban |
| Posted: Wed Dec 19, 2001 8:04 am Post subject: |
|
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
| Hmmm lots of reasons that triggering may not happen ... does the triggered program put itself in the background? Not 100% certain but think that the triggered program blocks the trigger monitor until it completes .... |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Dec 19, 2001 8:07 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7716
|
To prove Kolban's theory, the next time the trigger doesn't happen, look in the init queue. Is there a trigger message there, waiting to be picked up?
What's your trigger type?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| EddieA |
| Posted: Wed Dec 19, 2001 9:46 am Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
Hi,
Kolban is correct if it's Trigger type First. One of the conditions for a trigger to happen is that the queue being triggered is NOT currently open.
In response to Peter's comment. I don't think there is any condition where you will find a record in the INIT queue, because unless all the conditions are met, which includes an open connection on the INIT queue, MQ will not write that trigger message.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Dec 19, 2001 2:50 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7716
|
Eddie,
I set up a queue to trigger on Every. If the process that is triggered starts up in the foreground, then the trigger monitor will not go to the init queue for another message until the first trigger app it started ends.
So in the above case, I drop 1 message to QueueA (Trigger Every), and my app pops up on the screen. I drop a second message on QueueA, and now I see a trigger message waiting on the init queue. If I continue dropping messages to QueueA, as long as there is a triggered application running, the Queue Manager faithfully keeps producing trigger message, but the trigger monitor ignores them, causing the Init queue depth to rise.
If I stop that first triggered app, the trigger monitor pulls ONE message of the init queue, and starts up ONE instance of the app.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| EddieA |
| Posted: Wed Dec 19, 2001 4:14 pm Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
Peter,
OK. That's down to the design of the Trigger Monitor. I'm used to starting the application as a background task. At that point, while the application is still running, the Monitor will fire immediately the next Trigger Message appears.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| Manishkj |
| Posted: Wed Dec 19, 2001 11:24 pm Post subject: |
|
|
Newbie
Joined: 11 Nov 2001
Posts: 9
|
|
| Back to top |
|
|
| Manishkj |
| Posted: Wed Dec 19, 2001 11:34 pm Post subject: |
|
|
Newbie
Joined: 11 Nov 2001
Posts: 9
|
Thanks to all for their response.
Here are the answer to the question raised by you.
1. Trigger Type is FIRST.
2. There were no messages in the init queue when triggering does not happen.
3. Triggered application does not run in the background.
4. Application has been designed such that it will read all the message from the queue once it has been triggered.
This happens quite infrequently and we are unable to simulate it in test environment.
But the funny part is once we restart the trigger monitor trigger happens as normal ?
|
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Dec 20, 2001 7:42 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7716
|
You didn't give details as to the conditions that exists when you see a problem, so the below is my best guess at what could be going on. It is the most common problem with trigger OnFirst.
Trigger messages will only be generated for OnFirst queues when the depth goes from 0 to 1. If for some reason the app goes down after being triggered but new messages keep arriving, the Queue Manager will not send another trigger message. If you fixed your app in the meantime, you would find yourself with a queue with messages in it, with messages arriving, and no triggers.
They way to get around this is to take advantage of the TriggerInterval value on the Queue Manager. It is a value coded in milliseconds. If you set it at 600,000 (10 minutes), it would mean that if it has been at least 10 minutes since the queue manager last generated a trigger message, and a new message has just arrived, generate a trigger message (even if the queue depth is not going 0 to 1, but say 100 to 101).
Make sure you set this value high enough so that your app has a chance to keep the queue depth at zero during normal operations, otherwise if the queue gets backlogged, another trigger message will be generated even though everything is working normally. In this case your trigger On First queue starts acting more like trigger every. We coded this value at 10 minutes in our orginization and it works great. The only bad thing is that it is done at the QMGR level, so all queues that are triggered Onfirst get the same value.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Manishkj |
| Posted: Thu Dec 20, 2001 8:07 pm Post subject: |
|
|
Newbie
Joined: 11 Nov 2001
Posts: 9
|
Thanks Peter ,
Wow!!
I just checked the trigger interval for our q-manager is 10000 i.e 10 seconds only(I suppose it must be default as we have never configured it).
In this case your explaination may not hold good. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Dec 21, 2001 6:56 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7716
|
The default is 999,999,999, so someone was dinking with it at some point. Maybe they changed it to 10K when your problems were occuring and since then there has been no reoccurance of the prob?
If the problem was still occuring with the trig interval set to this value, you got me stumped. Maybe the trigger monitor was not running in those cases?
OOOOORRRRR, I just thought of this possability. If the first message to be put to a trigger-on-first-queue is the one that makes the queue depth go from zero to one, AND that message is PUT under syncpoint, then even though the QMGR generates a trigger message to the INIT queue, the trigger message is not hardened (and thus not available to the trigger monitor), until the unit of work for that first PUT message is commited or backed out.
Keep in mind that if that first UOW is followed by other messages being put to the queue, even if those are not under syncpoint, until that first is commited or rolled back, there is no triggering happening and you have stranded messages. Once that commit or backout happens, you are ok, if not delayed. However if that first application never commits (endless loop or something), you wont get your application triggered (but will have an uncommitted, unavailable trigger message on the INIT queue).
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Manishkj |
| Posted: Sun Dec 23, 2001 9:53 pm Post subject: |
|
|
Newbie
Joined: 11 Nov 2001
Posts: 9
|
Thanks Peter,
Yes you are correct the default TRIGINT is 99999999. I checked our Q-manager creation scripts, We did indeed change the TRIGINT to 10000 after creation of Q-Manager. All the while it has been to 10000!!!
I have also verified that application don't put the message under SYNCH POINT. And when the problem happened I have also verified that trigger monitor was running i.e unix process was there. Has somebody faced a situation where trigger monitor process is running but it is just freezed or hanging ? |
|
| Back to top |
|
|
| ramsi |
| Posted: Thu Feb 19, 2004 7:34 pm Post subject: Triggering not happening with 100% CPU utilization |
|
|
Newbie
Joined: 19 Feb 2004
Posts: 4
|
Hi,
We have MQ Series running on windows 2000 server. We created 40 different queues for various tasks in our MQ Series. And for each queue we have one init queue and one trigger monitor created. We have two problems:
1. Even after the messages are cleared the init Queue shows different count. For e.g. if 1000 msgs comes into Queue 2 then even after the msgs are dequeued and committed to the DB at the backend...the init queue still shows 900...899...898........700......694....610...500.........10.9.8.7...1
But once the INIT queue drops to 0 then the next msg queue starts processing
2. I don't know whether this is a related problem or not but when the init Q is still showing that it has msgs in it, the CPU spikes up to 100% which results in hanging the other set of queues coming into the same Queue or different Queue. It can't process the second set bcos of 100% CPU utilization.
Can you tell us what could be wrong in our configuration and what could be the best possible solution? FYI, we set the message queues as Non-persistent and we get 10 or 5000 msgs per second. I really appreciate if you could give me your suggestions based on your experience
Thanks,
Ramsi |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Feb 20, 2004 4:49 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Do NOT post the same question twice.  
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
