| Author |
Message
|
| i.x |
 Posted: Sat Mar 05, 2005 8:54 am Post subject: |
 |
|
Apprentice
Joined: 11 Aug 2004
Posts: 26
|
| JT wrote: |
| Quote: |
| ....and the trigger on LQ1 happens at 2:15. " |
How are you determining this time? Is this the time you see the message leave LQ1 or is this the time that your Perl script is started or is this perhaps the time that the Perl script first logs the event, i.e. "I'm awake"? |
When the perl script is running (triggerd on), itis creating a log entry for example
"2:15:32 am | ******Starting Script******"
"2:15:33 am | Reading messages out from LQ1"
etc...
This is how i determine this time. After the log entry " messages are put to Queue LQ2", the messages are out of LQ1 and i can browse them on LQ2 ..
I only discoverd this error, because i have installed the MQ Monitoring of Tivoli. (IBM Websphere Components).
I defined in the ressource model, that if a message in a queue is older than 15 minutes, than i critical alert should be send.
So i discovered the problem! Before i don't see it because of i am not looking all the time on the queue manager... |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Sat Mar 05, 2005 9:43 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| i.x wrote: |
So i look at my mq properties and here is it:
Trigger Interval: 999999999
Maximum Uncommited messages: 10000
Maximum open handles: 256
The trigger type on my queue is "First"
|
Leaving the trigger interval at the default is not a very healthy setup for an environment using triggers. You do not want to have to wait for about 11 days if there is some kind of a problem.
Thanks Peter for setting me straight with the right parameter name. Looks like my memory is decaying even faster than my teeth...  |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat Mar 05, 2005 10:08 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| i.x wrote: |
Can you explain how i get the IPROCS under the MQ Explorer? and which effects this value have for the delay time?
|
Do a properties on the queue in question, and go to the Statistics Tab.
A trigger on first queue will only fire a trigger message if the IPROCS on the queue is 0. A zero IPROCS means no one has the queue open for GETS. If the IPROCS on this queue is > 0 when the message lands (maybe your last instance of the program hasn't MQCLOSED the q yet), the the QM will not create a trigger message. When the IPROCS finally does go to 0, the QM sees a triggered on first queue with a depth > 0 going to an IRPOCS of 0 - which means create a trigger message.
This is just a guess...its hard to figure out your problem without seeing what you are seeing at the exact time the problem happens. But this is the only way I can think of a 15 minute delay for triggering if your trigger interval is 999999999, which it is. (but should be lowered for other reasons not related to this problem)
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| i.x |
| Posted: Sat Mar 05, 2005 10:23 am Post subject: |
|
|
Apprentice
Joined: 11 Aug 2004
Posts: 26
|
Hello,
I will look for the IPROCS value if the problem is coming up.
I will try to rebuild the situation on a test system and look for it.
I will also set down the trigger interval...
@ PeterPotkay:
| Quote: |
| Do a properties on the queue in question, and go to the Statistics Tab. |
Which field value is the IPROCs value ?
I have:
* open input count
* open output count
* Current depth
and some alter and creation dates... |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat Mar 05, 2005 10:31 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
peep the code of this app. When started (triggered) it should:
MQCONN
MQOPEN the triggered queue
Loop until 2033 "error"
MQGET
End Loop
MQCLOSE (immediatly!)
MQDISC
terminate.
Thats another important note, the executable must end also. If it does MQCLOSE the queue, and thus IPROCS are 0, the QM will generate a trigger message if another message lands, but the trigger monitor will not fire up another one of apps if it sees the old one still running. The trigger message will sit on the init queue.
That is an important point. The generation of a trigger message and the triggering of your app are NOT the same thing. The manual goes into great detail as to what causes a trigger message. But it does not go the next step and talk about in great detail exactly what condition the trigger monitor needs to succesfully process that trigger message.
So while you look at IPROCS on this "problem" queue, also look at the code, and also look at the INIT queue depth while the problem is occuring. It is possible that the trigger message sits on the INIT queue for 15 minutes, waiting for your executable to terminate.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| i.x |
| Posted: Sat Mar 05, 2005 10:35 am Post subject: |
|
|
Apprentice
Joined: 11 Aug 2004
Posts: 26
|
| PeterPotkay wrote: |
So while you look at IPROCS on this "problem" queue, also look at the code, and also look at the INIT queue depth while the problem is occuring. It is possible that the trigger message sits on the INIT queue for 15 minutes, waiting for your executable to terminate. |
That's it 
The trigger message sits on the init queue.. i can see it because of i defined a queue by itself for triggering.
And in the INIT queue the "trigger message" stands... that means that the application is not ended (in view of the qm?!), am i right? then i know where i have to look at.. if this is it... |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat Mar 05, 2005 10:38 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| i.x wrote: |
| And in the INIT queue the "trigger message" stands... that means that the application is not ended (in view of the qm?!), am i right? than i know where i have to look at.. if this is it... |
I think you are on the correct path.
If you see a stranded trigger message in the INIT queue, and you also see your triggered app still running, kill it. I bet the trigger monitor will eat that trigger message right up, and restart your app.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| i.x |
| Posted: Sat Mar 05, 2005 10:40 am Post subject: |
|
|
Apprentice
Joined: 11 Aug 2004
Posts: 26
|
| PeterPotkay wrote: |
| i.x wrote: |
| And in the INIT queue the "trigger message" stands... that means that the application is not ended (in view of the qm?!), am i right? than i know where i have to look at.. if this is it... |
I think you are on the correct path.
If you see a stranded trigger message in the INIT queue, and you also see your triggered app still running, kill it. I bet the trigger monitor will eat that trigger message right up, and restart your app. |
and if the application is not running at the same time?
i think windows don't get this right, because i don't send an exit signal by the perl script....
i think we've got it |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat Mar 05, 2005 10:40 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| i.x wrote: |
Which field value is the IPROCs value ?
I have:
* open input count
* open output count
* Current depth
and some alter and creation dates... |
IPROCS = open input count
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Mar 06, 2005 6:24 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| PeterPotkay wrote: |
| Thats another important note, the executable must end also. If it does MQCLOSE the queue, and thus IPROCS are 0, the QM will generate a trigger message if another message lands, but the trigger monitor will not fire up another one of apps if it sees the old one still running. The trigger message will sit on the init queue. |
That is the main reason why we execute triggered applications in the background.
Unix use & at the end of the line.
Windows use start at the beginning of your command
The trigger monitor calls a script that sets up the environment and than calls the command putting it in the background. After that the script terminates while the triggered app is really just starting. So the condition that the triggered app must have finished is always met.
Yes it does limit debugging to the logs, but then what else is new ? Shouldn't your triggered app have already been tested as a stand alone?
Enjoy  |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sun Mar 06, 2005 6:43 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| fjb_saper wrote: |
| The trigger monitor calls a script that sets up the environment and than calls the command putting it in the background. After that the script terminates while the triggered app is really just starting. So the condition that the triggered app must have finished is always met. |
Yes, and in the case where one trigger monitor is watching an INIT queue that is specified by many triggered queues, it is even more important that this is done. Queue1 sets of a trigger, which starts off App1. If App1 takes a while to complete, the trigger monitor can't go back to the INIT queue to look for other trigger messages from other triggered queue until App1 ends.
I have heard of people having one trigger monitor and one init queue for every triggered queue to get around this problem. This is totally unnecessary. One trigger monitir can handle dozens of triggered queues with just one INIT queue for all, provided these apps start in the background, so the trigger monitor is not stuck waiting on them to end.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
