- Error Handling Reuse
- Error Handling Use Cases
- Catch Exception Strategy Behavior
- Choice Exception Strategy Behavior
- Rollback Exception Strategy Behavior
- Exception-Transaction Architecture Clean Up
- Outlines for Error Handling Doc Page Cluster
Overview and Strategy
Why improve Error Handling in Mule 3.3?
Even though error handling has undergone a fair amount of work since Mule 2 there are still significant quality and usability issues that need to be addressed.
- Simple use cases (catch) cannot be implemented out of the box and require custom code.
- Most common use cases are difficult to implement using <default-exception-strategy>
- Complex to define custom behavior
- Poor documentation
- Documentation does not explain basic things as which is the content of the Message being routed through exception strategy, what happen with the result of exception strategy functionality, how to implement a custom exception strategy, etc
- Complex to implement custom exception strategy
- Lot of bugs have been reported, even with Mule 3.1/3.2.
- Error handling and transaction management is hard to test and lack tests.
- TransactionTemplate/ExceptionStrategy co-ordination broken in Mule 3.2.
- There are some inconsistencies between transports.
Error-Handling improvement stories
1) Improve Quality
- Error handling code is error prone due to the fact that is not centralized. Each component has custom code to manage exception which makes error handling error prone and not consistent. Error handling architecture clean-up will provide a centralized way to handle exception and make mule consistent.
2) Improve Documentation
- Create missing documentation for Mule 3.1.x and Mule 3.2.x. Certify it by written functional test cases. Write blogs first to improve visibility.
- For each new feature documentation and blogs are part of the story acceptance criteria. Testing will certify that provided functionality does what acceptance criteria describes and that documentation describes the same behavior as acceptance criteria
3) Provide missing functionality, Simplify existing functionality.
Leave <default-exception-strategy> as it is
Implement new exception strategy element/s that simplifies configuration for most common use cases
Route last state message before exception into exception strategy MPs and then to a DLQ
Route original message before exception into exception strategy MPs and then to a DLQ
Route by exception type
Preserve payload after exception strategy executes
Stop flow based on exception type
Rollback transaction and send a notification (email)
4) Facilitate creation of custom exception strategies
- Implement TemplateMethod in order to simplify custom exception strategies implementation
*5) Improve Error Example
---- 3.3 M1 ---
- 1) Documentation first (MULE-5899 FixVersion: M1)
- Improve existing Mule 3 documentation first since it has a great immediate impact in usability for Mule 3.1 and 3.2 users and it's low in effort.
- Also provides functional test coverage before implementation work.
- 2) Improve TransactionTemplate/ExceptionHandling architecture/(MULE-5911 FixVersion: M1)
- Significantly increase testability and unit tests before implementation work.
- Done in advance since it will affect every new feature
- Facilitates development of new features
- 3) Implement most need use case: "Catch and return result of error processing"
---- 3.3 M1 ---
---- 3.3 M2 -> ---
- 4) Implement/simplify other use cases
- Work with support and services to get feedback about most needed functionality
- Define use cases
- Prioritize use cases
- Create prototypes for each use case to get feedback
- Implement them
- Review them (Demo friday)
For each story: create a wiki page about it with documentation about proposed solution and try to get feedback from community and mule employees.
Mule 3.3 stories:
As a user I want much improved documentation for Mule 3.1/3.2 on how to configure the default-exception-strategy element to achieve common use cases
As a user I want to be able to continue processing a message when an error occurs returning the result of processing as a response
As I Mule developer I want to clean up the architectural relationship between transactions and exception strategies to improve maintainability and ensure solid foundation for other exception handling or transaction improvements
As a Mule developer I want to be able to route the original message to the exception strategy instead of the last state message before the exception
As a user I want to the ability rollback/commit a transaction in progress in a very intuitive way and based on exception type or message contents
As a user I want to the ability to stop a flow when an error occurs during normal flow processing if the exception is of a specific type
As a user I want to be able to define multiple named global exception strategies that can be referenced from and used by multiple flows
As a user I want to be able to define a custom default exception strategy that is used when a a flow or service does not define one explicitly
As a user I want to be able to use different error processing paths based on exception type or message contents
To be added
Create a centralized way to manage SystemExceptionHandling calls during flow execution. (Includes documentation about which exception are managed by MessagingExceptionHandling and which ones are managed by SystemExceptionHandling).
As a Mule developer I want to be able to define a custom exception strategy to customize some aspects of exception handling in a clean way. (Includes documentation about how to do it)
Detailed error handling problems
Documentation is poor, it doesn't explain:
- Which exception are going to be managed by MessagingExceptionHandler and which are going to be managed by SystemExceptionHandler.
- How a message is transformed before being routed to MessagingExceptionHandler.
- What happen with responses when a flow has MEP request-response and an exception is thrown.
- How to implement a custom exception strategy.
- How <default-exception-strategy> can be configured.
- What is the rule for commit/rollback a transaction.
- When transactions are resolved.
- When XA transactions are suspended/resumed.
Lot of bugs in Mule 3.1.x and 3.2.x:
- MULE-5808: Mule not invoking exception strategy when an exception is thrown in asynchronous flow
- MULE-5739: When configuring <default-exception-strategy> exception message is no longer routes to nested processor/endpoint unless configured to commit
- MULE-5738: When configuring <default-exception-strategy> inbound transaction is committed by default when no commit or rollback pattern is configured
- MULE-5801: custom exception handling don't work in http inbound
- MULE-5737: Flows does not handle exception when invoked via i) request-response vm inbound endpoint ii) flow-ref
- EE-2336: Exception-based Router Doesn't Work (Always RollsBack) XA Transactions
- EE-2340: Transaction contexts are not propagated to exception strategies
- EE-2389: Jms transaction is being commit after an exception in a component
- EE-2505: Transaction contexts are not propagated to exception strategies when the exception is thrown by the outbound-endpoint
- EE-2511: Transactions are resolved when they shouldn't. Response processor are not considerer
- EE-2534: Exception Strategy does not allow to modify payload (or invoke the response block)
Functionality provided is not what users need
- Users want to route message that was being processed before exception through exception strategy.
- Users want to route original message before being processed through exception strategy.
- Users want to route message based on exception type or content type.
- Users want to stop flow execution based on exception type.
- Users want to return the result of routing the message through exception strategy when inbound endpoint MEP is request-response.
- Users want to be able to reuse exception strategies or have a default one.
Complex to define custom behavior
AbstractMessagingExceptionStrategy in 3.1.x works as a Template method. So users can extend from it an override specific methods to change it's behavior. That was broken in 3.2.x and the way to create custom exception strategies is not straightforward.