ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » About Exception Handling

Post new topic  Reply to topic Goto page 1, 2  Next
 About Exception Handling « View previous topic :: View next topic » 
Author Message
emiddleware
PostPosted: Wed Feb 15, 2012 4:10 am    Post subject: About Exception Handling Reply with quote

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
View user's profile Send private message Send e-mail
mqjeff
PostPosted: Wed Feb 15, 2012 5:21 am    Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Wed Feb 15, 2012 5:22 am    Post subject: Re: About Exception Handling Reply with quote

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
View user's profile Send private message
smdavies99
PostPosted: Wed Feb 15, 2012 6:06 am    Post subject: Re: About Exception Handling Reply with quote

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
View user's profile Send private message
mqsiuser
PostPosted: Wed Feb 15, 2012 6:28 am    Post subject: Re: About Exception Handling Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Wed Feb 15, 2012 6:37 am    Post subject: Re: About Exception Handling Reply with quote

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
View user's profile Send private message
mqsiuser
PostPosted: Wed Feb 15, 2012 6:46 am    Post subject: Re: About Exception Handling Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Wed Feb 15, 2012 6:54 am    Post subject: Re: About Exception Handling Reply with quote

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
View user's profile Send private message
mqsiuser
PostPosted: Wed Feb 15, 2012 6:57 am    Post subject: Re: About Exception Handling Reply with quote

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
View user's profile Send private message
deepnair
PostPosted: Wed Feb 15, 2012 7:14 am    Post subject: Reply with quote

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
View user's profile Send private message
mqsiuser
PostPosted: Wed Feb 15, 2012 7:22 am    Post subject: Reply with quote

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
View user's profile Send private message
mqjeff
PostPosted: Wed Feb 15, 2012 7:23 am    Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Wed Feb 15, 2012 7:25 am    Post subject: Re: About Exception Handling Reply with quote

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
View user's profile Send private message
mqsiuser
PostPosted: Wed Feb 15, 2012 7:32 am    Post subject: Reply with quote

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
View user's profile Send private message
deepnair
PostPosted: Wed Feb 15, 2012 7:41 am    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » About Exception Handling
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.