| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Different back-out behaviour for different MQInput terminals |
« View previous topic :: View next topic » |
| Author |
Message
|
| prasadpav |
 Posted: Thu Jan 13, 2011 8:44 am Post subject: Different back-out behaviour for different MQInput terminals |
 |
|
Centurion
Joined: 03 Oct 2004
Posts: 142
|
Hi,
I've a very simple requirement to reset the MQ expiry to unlimited for all messages landing on back-out queues. While testing it, I came across the following behaviour which is different to what I expected it would be. I've set back-out threshold as "2" on my input queue properties.
| Quote: |
Behaviour #1: Message processing fails after message is propagated to "out" terminal of MQInput node
In this case, message is tried 2 times, then back-out threshold is reached and message is propagated to the failure terminal. Note, message arriving into the failure termial is the 3rd time the same message is entering the message flow |
| Quote: |
Behaviour #2: Message validation fails in MQInput node.
I've the following wiring:
| Code: |
| MQInput (Failure terminal) --> "compute node doing some processing" ---> Throw node (i.e. the i'm throwing an exception in the failure path) |
In this case, message is tried 2 times along the failure terminal, then back-out threshold is reached and message is put straight on the back-out queue. No 3rd entry to Failure terminal this time. |
In Behaviour #2, I expected MQInput node to generate a brand-new expection saying that message dequeue failed when the back-out threshold is reached (just like it did for "Behaviour #1") ??
I'm using Message Broker 6.1.0.3 on AIX.
Last edited by prasadpav on Fri Jan 14, 2011 5:47 am; edited 1 time in total |
|
| Back to top |
|
 |
| optimist |
| Posted: Fri Jan 14, 2011 5:33 am Post subject: |
|
|
Apprentice
Joined: 18 Nov 2010
Posts: 33
|
Here is the content from WMB 6 Info Center for handling "Internal Errors"...
| Quote: |
•The MQInput node detects an internal error in the following situations:
◦A message validation error occurs when the associated message parser is initialized.
◦A warning is received on an MQGET.
◦The backout threshold is reached when the message is rolled back to the input queue. |
| Quote: |
•If the MQInput node detects an internal error, one of the following actions occur:
◦If you have not connected the Failure terminal, the MQInput node attempts to put the message to the input queue's backout requeue queue, or (if that is not defined) to the dead letter queue of the broker's queue manager. If the put attempt fails, the message is rolled back to the input queue. The MQInput node writes the original error and the MQPUT error to the local error log. The MQInput node now invokes the retry logic, described in Retry processing.
◦If you have connected the Failure terminal, you are responsible for handling the error in the flow connected to the Failure terminal. The broker creates a new ExceptionList to represent the error and this is propagated to the Failure terminal as part of the message tree, but neither the MQInput node nor the broker provide any further failure processing . |
Based on the above, in your scenario #2, we should expect the message to be sent to the Failure node the first time an internal error such as the validation error occurs...
Seems like a bug if it is not working as above! |
|
| Back to top |
|
|
| prasadpav |
| Posted: Fri Jan 14, 2011 5:49 am Post subject: |
|
|
Centurion
Joined: 03 Oct 2004
Posts: 142
|
[To Optimist]
Sorry, I did not explain the MQInput wiring in the case of "Behaviour #2". It is done now in my original post. |
|
| Back to top |
|
|
| optimist |
| Posted: Fri Jan 14, 2011 8:03 pm Post subject: |
|
|
Apprentice
Joined: 18 Nov 2010
Posts: 33
|
It now makes a lot more sense than it did previuosly!
In scenario 1, after each failure to process the message from the "out" terminal, the message is put back into the input Q. The second time the message is returned to the input Q, the backout count equals 2 and the message is sent to Failure.
Scenario 2 is an internal error in that the validation fails and so, trying 2 times is NOT to process the message from the Out terminal, but rather for Failure notification. So, after the second try, it makes sense to put the message on to the backout requeue Q (if one is defined) or if not, to the DLQ etc.
The behavior (with BOTHRESH set to 2) is then:
1. Failure to process the message on the "Out" terminal (not an internal error) two times results in the message sent to the Failure terminal
2. Failure to send the message two times to the Failure terminal (due to an internal error) results in the message going to requeue queue
Seems logical to me, though I would not have guessed this to be the case... Thanks. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
