| Author |
Message
|
| aotto1968-2 |
 Posted: Fri Aug 25, 2006 12:04 am Post subject: trigger-monitor is fire triggers on empty queue |
 |
|
Newbie
Joined: 21 Aug 2006
Posts: 4
Location: Munich
|
Dear Admins,
I have a problem with the trigger for a local queue ...
it seems for me that the trigger-monitor is fire a trigger for
a local queue. the reason for this is that they are still messages
in the INIT queue for the local queue even if the queue itself is empty.
there are more init messages because usually after the first
init-messages arrive the according trigger is cleaning the entire
queue and init messages are left over.
I allready have: Trigger type FIRST on the queue but the spoolout
application puts sometimes additional massages in the INIT queue
the core problem is that the trigger-monitor is firing the trigger even
the queue is allready empty
i dont know why because it should be easy to check CURDEPTH first
mfg
Andreas Otto |
|
| Back to top |
|
 |
| Vitor |
| Posted: Fri Aug 25, 2006 12:46 am Post subject: Re: trigger-monitor is fire triggers on empty queue |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| aotto1968-2 wrote: |
I allready have: Trigger type FIRST on the queue but the spoolout
application puts sometimes additional massages in the INIT queue
|
Is "spoolout" something you've written? Is it writing directly to the Initiation queue? If it is, it shouldn't!
So is your scenario that the application is being triggered on FIRST but there's no messages in the relevant queue? If so, are you sure the application message is being committed?
You want to use the search facility on the forum, or Google it now it's (apparently) indexed. This sort of thing has been discussed before in various combinations and guises.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Aug 25, 2006 12:50 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
On the plus side, well behaved programmes going off when they shouldn't are not a problem. Waste of resoruces perhaps and something to be got to the bottom of, but better too many triggered programmes than too few (within reason obviously - or we end up with the nightmare of trigger EVERY!)
Do the search. Lot of good stuff in here about triggers. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| aotto1968-2 |
| Posted: Fri Aug 25, 2006 1:19 am Post subject: Re: trigger-monitor is fire triggers on empty queue |
|
|
Newbie
Joined: 21 Aug 2006
Posts: 4
Location: Munich
|
Is "spoolout" something you've written? Is it writing directly to the Initiation queue? If it is, it shouldn't!
> the spoolout script is not written by me and I'm not be able to get it modified
the core question is:
why is the trigger-monitor firering a trigger even if the queue is empty?
from my point of view: the trigger-monitor should do the following:
1. get a message from the init-queue
2. check if still a message is message is available in the local queue
3. if yes -> fire the trigger
4. if no -> forget about the init-message
this is the expected behaviour |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Aug 25, 2006 1:26 am Post subject: Re: trigger-monitor is fire triggers on empty queue |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| aotto1968-2 wrote: |
from my point of view: the trigger-monitor should do the following:
1. get a message from the init-queue
2. check if still a message is message is available in the local queue
3. if yes -> fire the trigger
4. if no -> forget about the init-message
this is the expected behaviour |
Not expected by me it isn't! 
There are good reasons why the init message could preceed the actual message. Indeed the documentation states, after discussing the uncommitted scenario I alluded to in the previous post:
| Quote: |
| However, this means that trigger messages are sometimes created when the conditions for a trigger event are not satisfied. Applications that use triggering must always be prepared to handle this situation. It is recommended that you use the wait option with the MQGET call, setting the WaitInterval to a suitable value |
(Application Programming Guide, Chapter 14, page 192)
Now clearly if the application is being triggered before commit then logically rollback is a possibility. Hence your application may never receive a message. It's all down to the design.
But sounds like triggering is funtioning as designed.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Aug 25, 2006 1:29 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
One important point here - the supplied trigger monitor is nothing more than an MQ long running program designed to read init messages and start the required application. There is no reason why you couldn't write your own if the supplied one doesn't met your requirements (i.e. checking the depth of the application queue before starting the application).
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| wschutz |
| Posted: Tue Aug 29, 2006 2:34 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
| Vitor wrote: |
| There is no reason why you couldn't write your own if the supplied one doesn't met your requirements (i.e. checking the depth of the application queue before starting the application). |
But what happens if a message arrives on the queue right after you've checked the qdepth?
_________________
-wayne |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Aug 29, 2006 2:36 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| wschutz wrote: |
| Vitor wrote: |
| There is no reason why you couldn't write your own if the supplied one doesn't met your requirements (i.e. checking the depth of the application queue before starting the application). |
But what happens if a message arrives on the queue right after you've checked the qdepth? |
The message doesn't get processed, a defect's raised against the system and you go back to using the supplied trigger monitor because it works better! 
I just said you could - I certainly wouldn't.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Tue Aug 29, 2006 4:36 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| Quote: |
the core problem is that the trigger-monitor is firing the trigger even
the queue is allready empty
|
No, the core problem is
| Quote: |
but the spoolout
application puts sometimes additional massages in the INIT queue |
The application should not just place a message onto the initq unless it is a correctly formatted trigger message. 
As already mentioned this scenario is triggering working as designed, your spoolout application is the one that is throwing a spanner into the works. 
[/b] |
|
| Back to top |
|
|
|
|
