[CONF] Apache Camel: Error Handler (page edited)

Sat, 03 Jan 2009 10:34:35 -0800

Page Edited : CAMEL : Error Handler

Error Handler has been edited by Claus Ibsen (Jan 03, 2009).

Change summary:

polished

(View changes)

Content:

Error Handler

Camel supports pluggable ErrorHandler strategies to deal with errors processing an Event Driven Consumer. An alternative is to specify the error handling directly in the DSL using the Exception Clause.

Some current implementations include

Transaction

If the route is transactional then the Dead Letter Channel is disabled. The exchange.isTransacted() is used to determine if an Exchange is transacted or not.
So if you are using transacted routes then you should configure the TransactionErrorHandler instread of DeadLetterChannel. See Transactional Client for further details and samples.

Exception Clause

Using Error Handler combined with Exception Clause is a very powerful ally. We encourage end-users to use this combination in your error handling strategies. See samples and Exception Clause.

These error handlers can be applied in the DSL to an entire set of rules or a specific routing rule as we show in the next examples. Error handling rules are inherited on each routing rule within a single RouteBuilder

Short Summary of the provided Error Handlers

Default Error Handler (Dead Letter Channel)

The default error handler is the Dead Letter Channel which is automatically configured for you. By default Camel will redeliver at most 6 times using 1 second delay, and if the exchange failed it will be logged at ERROR level.

You can configure the default dead letter endpoint to use:

RouteBuilder builder = new RouteBuilder() {
    public void configure() {
        errorHandler(deadLetterChannel("seda:errors"));
        from("seda:a").to("seda:b");
    }
};


Logging Error Handler



The logging error handler will log (by default at ERROR level) whenever an uncaught exception is thrown. The logging category, logger and level may all be defined in the builder.





errorHandler(loggingErrorHandler("mylogger.name").level(LoggingLevel.INFO));





This would create an error handler which logs exceptions using the category mylogger.name and uses the level INFO for all log messages created.




from("seda:a").errorHandler(loggingErrorHandler("mylogger.name").level(LoggingLevel.DEBUG)).to("seda:b");





Loggers may also be defined for specific routes.



No Error Handler



The no error handler is to be used for disabling error handling. 




errorHandler(noErrorHandler());





Scopes


The error handler is scoped as either


    
	
  • global
    • 
	
  • per route specific
    • 
	
  • or policy based (this applies for transactional exchanges only)
    • 





The following example shows how you can register a global error handler (in this case using the logging handler)




RouteBuilder builder = new RouteBuilder() {
    public void configure() {
        errorHandler(loggingErrorHandler("FOO.BAR"));
        from("seda:a").to("seda:b");
    }
};





The following example shows how you can register a route specific error handler; the customized logging handler is only registered for the route from Endpoint seda:a




RouteBuilder builder = new RouteBuilder() {
    public void configure() {
        from("seda:a").errorHandler(loggingErrorHandler("FOO.BAR")).to("seda:b");
        // this route will use the default error handler,
        // DeadLetterChannel
        from("seda:b").to("seda:c");
    }
};






Spring based configuration


Available as of Camel 1.4



Java DSL vs. Spring DSL


The error handler is configured a bit differently in Java DSL and Spring DSL. Spring DSL relies more on standard Spring bean configuration whereas Java DSL uses fluent builders.



In Camel 1.4 the error handler can be configured as a spring bean and scoped in:


    
	
  • global (the camelContext tag)
    • 
	
  • per route (the route tag)
    • 
	
  • per policy (the policy tag)
    • 





The error handler is configured with the errorHandlerRef attribute.



Error Handler Hierarchy


The error handlers is inherited, so if you only have set a global error handler then its use everywhere. But you can override this in a route and use another error handler.



Spring based configuration sample


In this sample we configure a Dead Letter Channel on the route that should redeliver at most 3 times and use a little delay before retrying.

First we configure the reference to myDeadLetterErrorHandler using the errorHandlerRef attribute on the route tag.




<camelContext id="camel" xmlns="http://activemq.apache.org/camel/schema/spring">
      <template id="myTemplate"/>
<!-- set the errorHandlerRef to our DeadLetterChannel, this applies for this route only -->
      <route errorHandlerRef="myDeadLetterErrorHandler">
          <from uri="direct:in"/>
          <process ref="myFailureProcessor"/>
          <to uri="mock:result"/>
      </route>
  </camelContext>





Then we configure myDeadLetterErrorHandler that is our Dead Letter Channel. This configuration is standard Spring using the bean element.

And finally we have another spring bean for the redelivery policy where we can configure the options for how many times to redeliver, delays etc.




<!-- here we configure our DeadLetterChannel -->
<bean id="myDeadLetterErrorHandler" class="org.apache.camel.builder.DeadLetterChannelBuilder">
    <!-- exchanges is routed to mock:dead in cased redelivery failed -->
       <property name="defaultDeadLetterEndpointUri" value="mock:dead"/>
	<!-- reference the redelivery policy to use -->
       <property name="redeliveryPolicy" ref="myRedeliveryPolicyConfig"/>
   </bean>

   <!-- here we set the redelivery settings -->
<bean id="myRedeliveryPolicyConfig" class="org.apache.camel.processor.RedeliveryPolicy">
    <!-- try redelivery at most 3 times, after that the exchange is dead and its routed to the mock:dead endpoint -->
       <property name="maximumRedeliveries" value="3"/>
	<!-- delay 250ms before redelivery -->
       <property name="delay" value="250"/>
   </bean>






Using the transactional error handler


The transactional error handler is introduced in Camel 1.4 and is based on spring transaction. This requires the usage of the camel-spring component.

See Transactional Client that has many samples for how to use and transactional behavior and configuration with this error handler.



See also


The Dead Letter Channel for further details.

The Transactional Client for transactional behavior

The Exception Clause as it supports handling thrown exceptions

Powered by Atlassian Confluence (Version: 2.2.9 Build:#527 Sep 07, 2006) - Bug/feature request

Unsubscribe or edit your notifications preferences

Reply via email to