| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| How you refer to Exception in failure terminal of MQInput? |
« View previous topic :: View next topic » |
| Author |
Message
|
| kirani |
 Posted: Fri May 17, 2002 8:11 am Post subject: How you refer to Exception in failure terminal of MQInput? |
 |
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
My queue manager and database is configured for 2-phase commit. In case of failure, I want to rollback and handle all my errors in Failure terminal of MQInput node.
I know that ExceptionList is not available in Failure terminal of MQInput node. I can think of following ways to refer to ExceptionList in Failure path.
In Catch terminal of MQInput node,
1. Write ExceptionList to some output queue. In failure terminal use MQGet node to retrieve this ExceptionList.
2. Insert ExceptionList into some database table (Transaction mode=commit) and then retrieve the same in Failure terminal.
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
 |
| CodeCraft |
| Posted: Sat May 18, 2002 12:19 am Post subject: |
|
|
Disciple
Joined: 05 Sep 2001
Posts: 195
|
Is this a question or an observation? Here's another:
Under what circumstances would you expect to enter the failure path rather than the catch path?
a) When the catch processing fails?
b) When the input node itself fails?
I think (though haven't tried) that failed catch processing can actually be caught by having a TryCatch node immediately after your MQInput, therefore, you rely on the TryCatch, and not your MQInput's catch, to trap exceptions. |
|
| Back to top |
|
|
| Cliff |
| Posted: Mon May 20, 2002 7:40 am Post subject: |
|
|
Centurion
Joined: 27 Jun 2001
Posts: 145
Location: Wiltshire
|
Kiran,
you need to handle your errors from the catch terminal of the MQInput node, not the failure terminal. There's no advantage in having a TryCatch node immediately after the MQInput node - you're not going to catch anything the MQInput node's catch wouldn't!
Remember that the DestinationList and the CHANGED mesage are not propagated backwards towards the MQInput node when an exception occurs - if you want/need to see the data at point of failure you should wire some kind of (ideally global) error handling subflow to all (except the MQInput) nodes' failue terminals. This subflow MUST end in a Throw node so control is returned to MQInput, where UOW backout is handled.
When the message is reprocessed at the MQInput node, if there is a subflow wired to the failure terminal, the message will be propagated there. This is AFTER any backout processing has taken place!
If you have specified backout requeue queue name on your input queue and the message is processed transactionally, and nothing is wired to the MQInput failure terminal, the message will be put to the backout queue.
I would recommend always using the backout requeue queue name, so you never lose your original input data and creating a global subflow to handle error reporting/recording which every node's failure terminal is wired to. Do any other error processing you want to at the MQInput catch terminal (still within the UOW) but make sure any MQPUTs are outside syncpoint and it ends with a Throw node so control always gets back to MQInput.
HTH - Cliff |
|
| Back to top |
|
|
| CodeCraft |
| Posted: Mon May 20, 2002 8:00 am Post subject: |
|
|
Disciple
Joined: 05 Sep 2001
Posts: 195
|
Wording problem!
Cliff, what I meant to get at here is, in order to catch errors in catch processing you might have a TryCatch wired to the catch terminal of the MQInput node.
Would I be correct in saying that if you have an exception in the exception handling process, and, you started from the MQInput's catch, then the only other place to go is MQInput's failure, wheras, if you have a TryCatch after the MQInput's catch, you can have a more basic handler.
This is more of a second chance error handler. I've seen people wire up some horribly complex error handlers, and in many cases the least tested piece of the application is the error handler ...
Regardling the use of a subflow wired to each failure terminal? Is there a benefit here - much of the processing within a flow may not even have a full message to output. I suppose one thing you can do is write the contents of whatever tree you have out as generic XML.
This is not a challenge - I think it's good to work through this as the various error handling options would not be clear to everyone. |
|
| Back to top |
|
|
| Cliff |
| Posted: Mon May 20, 2002 8:23 am Post subject: |
|
|
Centurion
Joined: 27 Jun 2001
Posts: 145
Location: Wiltshire
|
Hi,
sorry if that sounded a bit 'lectureish' but I know it's easy to misunderstand exactly what happens where in MQSI whoops, sorry, WMQI error processing.
If you have need to trap an exception in the MQInput catch processing then yes, a TryCatch down this leg is the way to go with the ususal caveat of ending in a Throw node.
The big point about the MQInput's failure terminal processing, is that when the message is propagated there, it is in a completely new UOW. The message has been rolled back onto the queue, a new MQGET has happened and so on. You will not have the ExceptionList that you're hoping for!
I guess there's no single solution to error handling. What I described I know to work well - we write ExceptionList and other data to files whose names reflect the message flow names and the arrival of a message on the backout queue triggers another process. This gives us diagnostic data and keeps the original data intact. Some people prefer to write diagnostic data to messages in a particular queue - horses for courses I guess.
The benefit of a global subflow wired to all the failure terminals is partly to do with standardisation and partly because this is te only place you can see the DestinationList and Message data as they are at point of failure. You also get the ExceptionList uncluttered with any other exception data that it may be embellished with as control returns to MQInput. Again, you have to decide how well that fits your needs. I rather like the first argument: if everyone always does it that way, then you know where to look for diagnostics.
I'd be very interested to hear how others approach this. Comments, anyone?
Kind regards - Cliff |
|
| Back to top |
|
|
| suneelsh |
| Posted: Mon May 20, 2002 9:26 am Post subject: |
|
|
Acolyte
Joined: 13 Apr 2002
Posts: 69
Location: Pune,India
|
whew! this forum is heating up!
I think cliffs solution sounds clean and logical to the problem stated above.
I must say this has broadened my view on exception handling in MQSI..oops WMQI  |
|
| Back to top |
|
|
| kirani |
| Posted: Mon May 20, 2002 3:11 pm Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
Thanks for your input guys.
My apologies, if I wasn't clear enough in stating the problem. But this is leading to good discussion !!
I have done lots of thinking and testing about error handling. I am designing a common error handling sub-flow that can be used by our developers in their message flows. All my message flows will be configured to use coordinated transactions. My objective is to,
1. Identify different types of errors(Critical and non-critical).
2. If any error occured in a message flow, I should,
a) rollback DB updates (which WMQI will take care of using 2-phase commit).
b) log error information (Log ExceptionList into Database)
c) Log Original Message into database.
3. For Critical errors,
a)I want to stop my message flow processing by disabling the input queue. (Many thanks to Neil Kolban for developing MQDisable node!)
b)I want to retain original message on the input queue. (by using Throw node)
c)Page Production support person. (By putting a message on Error queue, tran=no, another subsystem will take care of paging, email, etc.)
d)Failed messages will be processed after the problem is resolved (by enabling input queue).
4. For Non-Critical Errors,
a) Continue with the next message.
I am able to meet these objectives in my error handling design. Since we are already logging actual message into the Database, we are not going to use any Backout queue to store backout messages. Backout threshold on input queues are set to 0.
Observations
------------
1. WMQI will rollback DB updates ONLY IF an error is thrown back to MQInput node. Let's say if you are handling errors in MQInput node's catch terminal, you must use Throw node to throw back the error to MQInput node. Now your message comes back on Input queue and db rollback occurs.
2. I can not use same database in two different modes, i.e. in one node transaction Mode set to Automatic, and in another node Transaction mode set to Commit. WMQI fails to do this. (soon we will open PRM with IBM regarding this)
Due to above two points, I must log errors into db in Failure path. I am hoping that WMQI will not fail if I use database node to log errors with transaction mode is set to commit. I am going to test this in a day or two.
3. Once your message comes back on the input queue after backout processing it is very difficult to recycle it (send it through out terminal). To do this you have to do some "black magic" , i.e.
a) You increased the backout threshold on the queue to higher value.
This is not a good idea.
b) You change backout count of the failed message.
This may result into incorrect message sequence.
I hope this explains the reason behind handling error messages in failure path.
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
| Cliff |
| Posted: Tue May 21, 2002 1:51 am Post subject: |
|
|
Centurion
Joined: 27 Jun 2001
Posts: 145
Location: Wiltshire
|
Hi, Kiran.
I agree that the fundamental problem is not being able to reliably mix and match DB I/O within and without the UOW - but you're still going to have a problem if you use the failure terminal, because the message will have been backed out and read anew with new trees generated. One answer may be from the catch terminal, to put a message with all the diagnostic data onto a queue which is input to another flow which does the database insert.
I haven't tried using a different ODBC source for error logging - have you? I vaguely recall reading some nonsense in the manual which gave some rules about when transaction mode was honoured, but I think we'd all prefer it simply to work as it should!
Let us know how you get on.
Cheers - Cliff |
|
| Back to top |
|
|
| kirani |
| Posted: Tue May 21, 2002 7:56 pm Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
Hi Cliff,
Due to following reasons I don't think I will have problem in failure terminal.
1. I am reading my messages as BLOB in MQInput node.
2. Only MQMD.Backoutcount would have changed in my failure path.
2. I don't refer to any other tree (Environment or LocalEnvironment) in my failure path.
As it stands now I can use the first option to propagate Exception to failure terminal.
I have tried using different ODBC source for error logging (in catch terminal) and it is not working. However, I am sure it will work in failure terminal. I will update you on this after I try it on my machine.
I would really love to hear about how transaction mode (in DB nodes) works in different scenarios 
Thanks!
Kiran
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
| kirani |
| Posted: Sun Jun 02, 2002 10:41 am Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
Cliff,
| Quote: |
| I have tried using different ODBC source for error logging (in catch terminal) and it is not working. However, I am sure it will work in failure terminal. I will update you on this after I try it on my machine. |
Using different ODBC DSN name in failure terminal works!
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| 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
|
|
|
|
