| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Error Handling - Documentation problems |
« View previous topic :: View next topic » |
| Author |
Message
|
| mkza.swe |
 Posted: Sat Jul 14, 2012 8:13 am Post subject: Error Handling - Documentation problems |
 |
|
Novice
Joined: 04 Jun 2012
Posts: 16
|
Hi! For many it seems that the error handling of the WMB is a bit tricky to understand. I have read many posts and it seems there are many common misunderstandings.
Especially the chart on this page gives me a headache:
http://publib.boulder.ibm.com/infocenter/wmbhelp/v7r0m0/index.jsp?topic=%2Fcom.ibm.etools.mft.doc%2Fac00414_.htm
What is the difference between "Node retries" and "Error logged, message rolled back"? Also the "Message put to alternative queue; node retries if the put fails", I'm not sure what that means... Does it bypass retry mechanism (backout threshold) and put directly on backoutQ/DLQ?
And in what cases does the Exception get logged, and not? That also seem a bit confusing. For "Error logged, message rolled back", it is kind of clear that exception gets logged, but what about "Node retries" etc?
Anyway... I have tried to make a schematic of what happens in different situations, according to my experience and what I read in the documentation, and I would be happy if anyone could verify it's correctness, or point out any errors in it:
For flows starting with MQ Input node. All terminal references refer to MQ Input node terminals, and assuming no other failure/catch terminals/mechanisms are present in the flow after the MQ Input node.
If FAILURE and CATCH terminal is connected:
- Message retries, when errors:
----- For BackoutCount < BOTHRESH:
---------- Error in MQInput Node -> Failure terminal
---------- Error after MQInput Node’s Out terminal -> Catch terminal
---------- Error after MQInput Node’s Catch terminal -> Rollback/retry & Error Log
---------- Error after MQInput Node’s Failure terminal -> Rollback/retry & Error Log
----- For BackoutCount >= BOTHRESH && BackoutCount < 2*BOTHRESH:
---------- Message go directly to Failure terminal.
---------- Error after MQInput Node’s Failure terminal -> Rollback/retry & Error Log (new exception type specifying retry threshold reached)
----- For BackoutCout = 2*BOTHRESH:
---------- Back Out -> BOQName or DLQ
If only FAILURE terminal is connected:
- Message retries, when errors:
----- For BackoutCount < BOTHRESH:
---------- Error in MQInput Node -> Failure terminal
---------- Error after MQInput Node’s Out terminal -> Rollback/retry & Error Log
---------- Error after MQInput Node’s Failure terminal -> Rollback/retry & Error Log
----- For BackoutCount >= BOTHRESH && BackoutCount < 2*BOTHRESH:
---------- Message go directly to Failure terminal.
---------- Error after MQInput Node’s Failure terminal -> Rollback/retry & Error Log (new exception type specifying retry threshold reached)
----- For BackoutCout = 2*BOTHRESH:
---------- Back Out -> BOQName or DLQ
If only CATCH terminal is connected:
- Message retries, when errors:
----- For BackoutCount < BOTHRESH:
---------- Error in MQInput Node -> Back Out -> BOQNAME or DLQ (No Rollback/retry???)
---------- Error after MQInput Node’s Out terminal -> Catch terminal
---------- Error after MQInput Node’s Catch terminal -> Rollback/retry & Error Log
----- For BackoutCount = BOTHRESH:
---------- Back Out -> BOQName or DLQ
Thank you! :) |
|
| Back to top |
|
 |
| smdavies99 |
| Posted: Sat Jul 14, 2012 11:28 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
In general you only need to attach the Catch terminal to the input node.
If you need to, you can always 'rethrow' the exception in the catch branch.
However, as you surmise, there are many facets to error handling in Broker.
You can be as simple or as comprehensive as you like. How much you do depends upon the requirements of your system.
Developing a comprehensive error handling subsystem is IMHO essential to the proper operation of a Broker system.
A simple tip is to put it all into a subflow. Then it can be maintained as a separate component. Any changed can easily be incorporated into the flow that is deployed.
A good deal of experimentation is essential. You will learn an awful lot about how broker works which will help you in future development tasks.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| 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
|
|
|
|
