| Author |
Message
|
| emiddleware |
 Posted: Wed Feb 15, 2012 4:10 am Post subject: About Exception Handling |
 |
|
Centurion
Joined: 03 Apr 2006
Posts: 120
|
I wanted to know that for high performance and better design, what exception handling mechanism do we use ?
_________________
Best Regards,
E-MiddleWare |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Wed Feb 15, 2012 5:21 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The appropriate one for the business requirements that define your understanding of "high performance".
And the appropriate one for the technical standards that define your understanding of "better design".
What color is the cow? |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Feb 15, 2012 5:22 am Post subject: Re: About Exception Handling |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| emiddleware wrote: |
| I wanted to know that for high performance and better design, what exception handling mechanism do we use ? |
Store the exception tree in a message, put that in a queue, put the original message in the same queue with it's correlation id set to the message id of the exception tree message & process them both in a separate asyncronous process leaving the original process to spin away.
Other, possibly better, solutions are undoubtably possible. Including writing an error line out with log4j (which I understand to be fast & effecient).
A lot depends on how high the throughput of this "high performance" flow is expected to be, how it's supposed to react to an error (report it, resolve it, etc) and what requirement there is for ticketing and logging.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Wed Feb 15, 2012 6:06 am Post subject: Re: About Exception Handling |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| emiddleware wrote: |
| I wanted to know that for high performance and better design, what exception handling mechanism do we use ? |
To add to Vitor's post,
What might be perfectly adequate in one organisation might be woefully inadequate in another.
Almost the first questions to be asked are:-
What error handling requirements are needed?
What logging and auditing functionality is mandatory?
There is no one single answer here.
Life is full of surprises, like my discovery today that some bits of PeopleSoft are written in COBOL.
_________________
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 |
|
|
| mqsiuser |
| Posted: Wed Feb 15, 2012 6:28 am Post subject: Re: About Exception Handling |
|
|
Yatiri
Joined: 15 Apr 2008
Posts: 637
Location: Germany
|
Offload the exception-handling from your main flow (as much as possible) !
Write a subflow (and a flow): In the subflow do some processing to put in the information from the exception-tree into the message. The subflow writes to a queue e.g. "LQ.EXCEPTIONS"
Decouple that write from the main transaction within the MQOutput-Queue properties:
| Code: |
Advanced -> "Transaction Mode" = "Automatic" --> "No" (decouple from the transaction of the flow)
Advanced -> "New message ID" = unchecked --> checked! (You create a new msg id)
Advanced -> "Message context" = "Pass All" --> "Set All" |
Write a flow to pick up and process these exception-messages from "LQ.EXCEPTIONS".
_________________
Just use REFERENCEs |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Feb 15, 2012 6:37 am Post subject: Re: About Exception Handling |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqsiuser wrote: |
Offload the exception-handling from your main flow (as much as possible) !
Write a subflow (and a flow): In the subflow do some processing to put in the information from the exception-tree into the message. The subflow writes to a queue e.g. "LQ.EXCEPTIONS"
Decouple that write from the main transaction within the MQOutput-Queue properties:
| Code: |
Advanced -> "Transaction Mode" = "Automatic" --> "No" (decouple from the transaction of the flow)
Advanced -> "New message ID" = unchecked --> checked! (You create a new msg id)
Advanced -> "Message context" = "Pass All" --> "Set All" |
Write a flow to pick up and process these exception-messages from "LQ.EXCEPTIONS". |
Which I think is what I said. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqsiuser |
| Posted: Wed Feb 15, 2012 6:46 am Post subject: Re: About Exception Handling |
|
|
Yatiri
Joined: 15 Apr 2008
Posts: 637
Location: Germany
|
| Vitor wrote: |
| Store the exception tree in a message, put that in a queue, put the original message in the same queue with it's correlation id set to the message id of the exception tree message & process them both in a separate asyncronous process |
Well... you are processing 2 messages (an exception and the message itself). My suggestion was to put the error info into the Message. I also provide 3 settings for configuration the MQOutput-queue on the errorhandling-subflow.
With "separate asynchronous process" Vitor means you deploy the Exception/Error-Processing-"flow" (that I talk of) into a separate execution group.
_________________
Just use REFERENCEs
Last edited by mqsiuser on Wed Feb 15, 2012 6:55 am; edited 1 time in total |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Feb 15, 2012 6:54 am Post subject: Re: About Exception Handling |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqsiuser wrote: |
| Well... you are processing 2 messages (an exception and a message). My suggestion was to put the error info into the main Message. I also provide detailed information for some parameters. |
Point taken, and I'm sure the OP is thankful for the fish.
| mqsiuser wrote: |
| With "separate asynchronous process" Vitor means you deploy the Exception/Error-Processing-"flow" (that I talk of) into a separate execution group. |
So a message put (as you suggest) outside a unit of work by 1 flow will not be picked up by a separate flow in the same execution group until the first flow has finished, i.e. in syncronisation with the first?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqsiuser |
| Posted: Wed Feb 15, 2012 6:57 am Post subject: Re: About Exception Handling |
|
|
Yatiri
Joined: 15 Apr 2008
Posts: 637
Location: Germany
|
| Vitor wrote: |
| So a message put (as you suggest) outside a unit of work by 1 flow will not be picked up by a separate flow in the same execution group until the first flow has finished, i.e. in syncronisation with the first? |
No, but each ExecGroup is a (OS-)process. If an execution group abends, it is better for your flows to be distributed among a couple of EGs.
Probably the platform's main exceptions processing flow deserves its own exec group !?
I thought that was your point !
_________________
Just use REFERENCEs |
|
| Back to top |
|
|
| deepnair |
| Posted: Wed Feb 15, 2012 7:14 am Post subject: |
|
|
Apprentice
Joined: 07 Feb 2012
Posts: 35
|
mqsiuser - on your below code
| Code: |
Advanced -> "Transaction Mode" = "Automatic" --> "No" (decouple from the transaction of the flow)
|
will this not make the thread hold on to a connection till the thread is complete ? So its like keeping a connection open till the flow completes ? When there are many flows deployed and multiple DB operations in an EG, the Automatic - No can impact the overall performance of transactions.
Thansk,
Deep Nair |
|
| Back to top |
|
|
| mqsiuser |
| Posted: Wed Feb 15, 2012 7:22 am Post subject: |
|
|
Yatiri
Joined: 15 Apr 2008
Posts: 637
Location: Germany
|
| deepnair wrote: |
| will this not make the thread hold on to a connection till the thread is complete ? So its like keeping a connection open till the flow completes ? When there are many flows deployed and multiple DB operations in an EG, the Automatic - No can impact the overall performance of transactions. |
The subflow gets wired to the Failure-Terminal of the MQInput-node. There a rollback already occured. I hope you do not do DB-Accesses in the error-subflow.
Though I am not 100% sure. Anybody else to comment ?
_________________
Just use REFERENCEs |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Feb 15, 2012 7:23 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| mqsiuser wrote: |
| Anybody else to comment ? |
there's a lot of previous discussion on this topic. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Feb 15, 2012 7:25 am Post subject: Re: About Exception Handling |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqsiuser wrote: |
| No, but each ExecGroup is a (OS-)process. If an execution group abends, it is better for your flows to be distributed among a couple of EGs. |
If an entire execution group has gone down, I put it to you that there are larger problems than the error handling of single flow. Like the quality of the recovery processes for all the working flows.
| mqsiuser wrote: |
| Probably the platform's main exceptions processing flow deserves its own exec group !? |
Perhaps. The point I was driving at is your post implied that a "separate asyncronous process" needed to be in a separate execution group, which is not the case. Desirable, but not essential.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqsiuser |
| Posted: Wed Feb 15, 2012 7:32 am Post subject: |
|
|
Yatiri
Joined: 15 Apr 2008
Posts: 637
Location: Germany
|
| mqjeff wrote: |
| mqsiuser wrote: |
| Anybody else to comment ? |
there's a lot of previous discussion on this topic. |
couldn't you have just said "yes (that is so right mqsiuser, but honestly) there's a lot of previous discussion on this topic." ?!?
_________________
Just use REFERENCEs |
|
| Back to top |
|
|
| deepnair |
| Posted: Wed Feb 15, 2012 7:41 am Post subject: |
|
|
Apprentice
Joined: 07 Feb 2012
Posts: 35
|
| Quote: |
| Probably the platform's main exceptions processing flow deserves its own exec group !? |
Agree with this 100%, the best way to handle exceptions and to avoid the EG's from getting thread hungry when there is too much load.
Thanks,
Deep Nair |
|
| Back to top |
|
|
|
|
