| Author |
Message
|
| velocity |
 Posted: Wed Aug 26, 2009 5:55 am Post subject: Triggering using FIRST |
 |
|
Centurion
Joined: 30 Nov 2007
Posts: 126
|
Hi Guys-
We are implementing triggering on a local queue using FIRST attribute.
When the first msg arrives on the queue, the application will be triggered. Lets say for some reason the application fails to process the msg, the msg will still be on the queue and that everything behind it would get stuck, since the queue depth would not be set back to zero.
Any ideas as to what happens when we face the above scenerio?
Thanks. |
|
| Back to top |
|
 |
| exerk |
| Posted: Wed Aug 26, 2009 6:09 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Yes - the queue fills until it's full (and all the attendant problems that will domino form that), or someone notices that everything is not all sweetness and light, and corrects it.
The answer to your (potential) problem lies within.............within a manual that is 
Hint: it's a queue manager attribute (but it would be nicer if it was a queue level one).
_________________
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 |
|
|
| velocity |
| Posted: Wed Aug 26, 2009 6:15 am Post subject: |
|
|
Centurion
Joined: 30 Nov 2007
Posts: 126
|
| I dont think the queue will fill up in this case. In this situation, if the application folks fix the application & if the second and third message arrives on the queue, will the application still be triggered until there are msgs on the queue? Pls let me know when you get a chance. |
|
| Back to top |
|
|
| velocity |
| Posted: Wed Aug 26, 2009 6:18 am Post subject: |
|
|
Centurion
Joined: 30 Nov 2007
Posts: 126
|
| Also the QM attribute TriggerInterval is set to 999 999 999 milliseconds. |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Aug 26, 2009 6:27 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| velocity wrote: |
| I dont think the queue will fill up in this case. |
Why not? If the application can't process the first message, what's to say it can process the subsequent messages. For triggered apps, always plan for a triggering failure, how to detect it, and how to deal with it.
| velocity wrote: |
| In this situation, if the application folks fix the application & if the second and third message arrives on the queue, will the application still be triggered until there are msgs on the queue? |
You are triggering on FIRST, therefore the trigger will not be reset until the trigger reset conditions are met.
| velocity wrote: |
| Also the QM attribute TriggerInterval is set to 999 999 999 milliseconds. |
Research this, it ties in with my first post.
_________________
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 |
|
|
| zpat |
| Posted: Wed Aug 26, 2009 6:29 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Set the TRIGINT of the queue manager to 60000.
I do this for all queue managers. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Aug 26, 2009 10:37 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| velocity wrote: |
| I dont think the queue will fill up in this case. |
Yes it will. The application will not be re-triggered and even if it was it's likely it will fail again when it tries to read the same message again.
| velocity wrote: |
| In this situation, if the application folks fix the application & if the second and third message arrives on the queue, will the application still be triggered until there are msgs on the queue? Pls let me know when you get a chance. |
Not unless the triggering conditions are met again as previously indicated.
Of course, the application problem can be obviated if the application checks the backout count before attempting processing. That way you avoid the poison message scenario and a simple restart fixes your problem. Unless you have message affinity (another good reason to design such affinity out).
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Aug 26, 2009 10:47 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
In another scenario, the trigger fires and the application is launched; but application fails (abends) before it MQGETs a message. (In this case, there is no message to backout, therefore no backout count.) Since no consuming app gets messages, the queue fills.
_________________
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 |
|
|
| Mr Butcher |
| Posted: Thu Aug 27, 2009 4:18 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
if trigger first and queue not empty an mqopen is suficient to create another trigger when queue is close not-empty by the last consumer.
and please notice that on non z/OS plattforms TRIGINT needs another message to arrive in the queue. otherwise no additional trigger will be created.
_________________
Regards, Butcher |
|
| Back to top |
|
|
|
|
