Author |
Message
|
warelock |
Posted: Thu Oct 21, 2010 7:41 am Post subject: Preventing infinite loop when rolling back in triggered app? |
|
|
Novice
Joined: 18 Jun 2010 Posts: 19
|
I have a Java MQ API app that will be triggered (MQTT_FIRST) when a message is put on our input queue. The app reads a message from the input queue and writes it to output queues depending on message content (the first 3 chars of the message payload). The read from the input queue and the write to the output queues are under one syncpoint (we want to commit or roll back the reads and writes for each input message as a UOW).
If the app reads an invalid message, we want to roll back the read and shut down the application. The application does shut down, but it looks like when we roll back the message the trigger fires again and relaunches the application. I think this makes sense if I understand the documentation about trigger conditions.
I've seen this problem described in various posts but I haven't been able to find a solution to it ! Hoping someone here can help me out with this - is there a way to roll back a message and stop the app without causing the trigger to start the app all over again ?
Thanks !! |
|
Back to top |
|
 |
mqjeff |
Posted: Thu Oct 21, 2010 7:54 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
What possible reason is there to stop the application in it's tracks when it receives a single bad message?
It should put the message on a backout queue and keep working.
You wouldn't stop your car in the middle of the highyway if you ran out of window washer fluid, would you?
If you really really think there's some valid reason for doing this, you can trigger on depth with a depth of 1. The MQ will disable triggering for you.
But the last thing that I want as an MQ administrator is to get paged in the middle of the night because a developer mistyped a constant in their program (or worse an end user mistyped a routing code in a data entry screen!) and this then caused the app to stop processing data and caused messages to pile up on an input queue until it got full. |
|
Back to top |
|
 |
warelock |
Posted: Thu Oct 21, 2010 8:23 am Post subject: trigger on depth with a depth of 1 |
|
|
Novice
Joined: 18 Jun 2010 Posts: 19
|
thanks for your thoughts, mqjeff.
the reason we want to stop the application is that all messages must be sent in order - something we cannot change in the exsting legacy apps (at least for the moment).
I think the concern with triggering on depth with a depth of 1 is that we might not trigger if we start up the queue manager with a depth > 1. Perhaps that is not a valid problem as I now think that when the queue manager starts the trigger will fire off.
I suppose, in addition, if the invalid message is the only one in the input queue when we roll back we would trigger. Granted that's a niche case.
Does that make sense? |
|
Back to top |
|
 |
warelock |
Posted: Thu Oct 21, 2010 9:52 am Post subject: trigger on depth not working? |
|
|
Novice
Joined: 18 Jun 2010 Posts: 19
|
To try this, I set up the trigger type to be MQTT_DEPTH with a TriggerDepth of 1.
However, this trigger fires only once; it processes the single message leaving the queue depth at 0. Then, when I place more messages on the queue, the trigger does not fire again. This is very puzzling to me ... ? |
|
Back to top |
|
 |
gbaddeley |
Posted: Thu Oct 21, 2010 3:00 pm Post subject: Re: trigger on depth not working? |
|
|
 Jedi Knight
Joined: 25 Mar 2003 Posts: 2538 Location: Melbourne, Australia
|
warelock wrote: |
To try this, I set up the trigger type to be MQTT_DEPTH with a TriggerDepth of 1.
However, this trigger fires only once; it processes the single message leaving the queue depth at 0. Then, when I place more messages on the queue, the trigger does not fire again. This is very puzzling to me ... ? |
With depth triggering, the app must reset the trigger every time it fires. _________________ Glenn |
|
Back to top |
|
 |
warelock |
Posted: Mon Oct 25, 2010 10:57 am Post subject: Re: trigger on depth not working? |
|
|
Novice
Joined: 18 Jun 2010 Posts: 19
|
gbaddeley wrote: |
warelock wrote: |
To try this, I set up the trigger type to be MQTT_DEPTH with a TriggerDepth of 1.
However, this trigger fires only once; it processes the single message leaving the queue depth at 0. Then, when I place more messages on the queue, the trigger does not fire again. This is very puzzling to me ... ? |
With depth triggering, the app must reset the trigger every time it fires. |
Thank you, Glenn. I am looking at this alternative. |
|
Back to top |
|
 |
mqjeff |
Posted: Mon Oct 25, 2010 11:12 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
Basically, if you want an app to be triggered normally, but come to a full stop after an exception, you have two choices.
The first is to disable triggering when you get an exception.
The problem with this is that your app could just completely crash and die before it got to the code to disable triggering, or it could experience an exception while trying to disable triggering.
The second option is to have triggering disabled automatically, and only enable it when your app ends gracefully. Trigger on Depth provides the first part of this for you. |
|
Back to top |
|
 |
warelock |
Posted: Mon Oct 25, 2010 12:31 pm Post subject: |
|
|
Novice
Joined: 18 Jun 2010 Posts: 19
|
mqjeff wrote: |
Basically, if you want an app to be triggered normally, but come to a full stop after an exception, you have two choices.
The first is to disable triggering when you get an exception.
The problem with this is that your app could just completely crash and die before it got to the code to disable triggering, or it could experience an exception while trying to disable triggering.
The second option is to have triggering disabled automatically, and only enable it when your app ends gracefully. Trigger on Depth provides the first part of this for you. |
Thank you very much, mgjeff ! The Force is strong in you I am testing this and it does indeed seem to give us the behavior we want. I am learning ... |
|
Back to top |
|
 |
|