[CONF] Apache Camel: Dead Letter Channel (page edited)

[confluence]

Page Edited : CAMEL : Dead Letter Channel Dead Letter Channel has been edited by Jonathan Anstey (Nov 07, 2008). (View changes) Content: Dead Letter Channel Camel supports the Dead Letter Channel from the EIP patterns using the DeadLetterChannel processor which is an Error Handler. Redelivery It is common for a temporary outage or database deadlock to cause a message to fail to process; but the chances are if its tried a few more times with some time delay then it will complete fine. So we typically wish to use some kind of redelivery policy to decide how many times to try redeliver a message and how long to wait before redelivery attempts. The RedeliveryPolicy defines how the message is to be redelivered. You can customize things like how many times a message is attempted to be redelivered before it is considered a failure and sent to the dead letter channel the initial redelivery timeout whether or not exponential backoff is used (i.e. the time between retries increases using a backoff multiplier) whether to use collision avoidance to add some randomness to the timings Once all attempts at redelivering the message fails then the message is forwarded to the dead letter queue. Redelivery default values The default redeliver policy will use the following values: maximumRedeliveries=5 delay=1000L (1 second, new as of Camel 2.0) use initialRedeliveryDelay for previous versions maximumRedeliveryDelay = 60 * 1000L (60 seconds, new option in Camel 1.4) And the exponential backoff and collision avoidance is turned off. The retriesExhaustedLogLevel and retryAttemptedLogLevel are set to LoggingLevel.ERROR The maximum redeliver delay ensures that a delay is never longer than the value, default 1 minute. This can happen if you turn on the exponential backoff. The maximum redeliveries is the number of re delivery attempts. By default Camel will try to process the exchange 1 + 5 times. 1 time for the normal attempt and then 5 attempts as redeliveries. Setting the maximumRedeliveries to a negative value such as -1 will then always redelivery (unlimited). Setting the maximumRedeliveries to 0 will disable any re delivery attempt. Camel will log delivery failures at the ERROR logging level by default. You can change this by specifying retriesExhaustedLogLevel and/or retryAttemptedLogLevel. See ExceptionBuilderWithRetryLoggingLevelSetTest for an example. Redelivery header When a message is redelivered the DeadLetterChannel will append a customizable header to the message to indicate how many times its been redelivered. The default value is org.apache.camel.redeliveryCount. The header org.apache.camel.Redelivered contains a boolean if the message is redelivered or not. Configuring via the DSL The following example shows how to configure the Dead Letter Channel configuration using the DSL RouteBuilder builder = new RouteBuilder() { public void configure() { errorHandler(deadLetterChannel("seda:errors")); from("seda:a").to("seda:b"); } }; You can also configure the RedeliveryPolicy as this example shows RouteBuilder builder = new RouteBuilder() { public void configure() { errorHandler(deadLetterChannel("seda:errors").maximumRedeliveries(2).useExponentialBackOff()); from("seda:a").to("seda:b"); } }; ExceptionPolicyStrategy (New feature in Camel 1.4) ExceptionPolicyStrategy is a strategy for resolving which rule (ExceptionType) should handle the given thrown exception. DeadLetterChannel supports pluggable strategies for resolving how exceptions should be handled. It is common to how different strategies for different types of exceptions. For instance network and IO related exceptions is more prone for network outages so the redeliver policy could have a higher attempts, timeouts etc. Where as a NullPointerException is typically a programming error so these kind of exception is severe and should not be redelivered. Camel uses a default strategy DefaultExceptionPolicyStrategy that applies the following rules: The exception type must be configured with an Exception that is an instance of the thrown exception If the exception type has exactly the thrown exception then its selected Otherwise the type that has an exception that is super of the thrown exception is selected (recurring up the exception hierarchy) The example below illustrates a common exception handling configuration in Camel: onException(NullPointerException.class) .maximumRedeliveries(0) .setHeader(MESSAGE_INFO, constant("Damm a NPE")) .to(ERROR_QUEUE); onException(IOException.class) .delay(5000L) .maximumRedeliveries(3) .maximumRedeliveryDelay(30000L) .backOffMultiplier(1.0) .useExponentialBackOff() .setHeader(MESSAGE_INFO, constant("Damm somekind of IO exception")) .to(ERROR_QUEUE); onException(Exception.class) .delay(1000L) .maximumRedeliveries(2) .setHeader(MESSAGE_INFO, constant("Damm just exception")) .to(ERROR_QUEUE); onException(MyBaseBusinessException.class) .delay(1000L) .maximumRedeliveries(3) .setHeader(MESSAGE_INFO, constant("Damm my business is not going to well")) .to(BUSINESS_ERROR_QUEUE); onException(GeneralSecurityException.class).onException(KeyException.class) .maximumRedeliveries(1) .setHeader(MESSAGE_INFO, constant("Damm some security error")) .to(SECURITY_ERROR_QUEUE); onException(InstantiationException.class, IllegalAccessException.class, ClassNotFoundException.class) .maximumRedeliveries(0) .setHeader(MESSAGE_INFO, constant("Damm some access error")) .to(ERROR_QUEUE); Here we have configured the handling of exceptions into three categories: NullPointerException (for special handling of these hard to track down bugs) IOException (for IO and network related issues we can attempt many times) Exception (fallback exception handling for all other kind of exceptions) Camel will with the default strategy try to select the best suited category from above for any thrown exception. So if a java.net.ScoketException is thrown then the IOException category will handle it. If a NumberFormatException or CamelExchangeException is thrown it is handled by the general purpose Exception category. Camel supports pluggable exception policy strategies. See Error Handler for such details. Using This Pattern If you would like to use this EIP Pattern then please read the Getting Started, you may also find the Architecture useful particularly the description of Endpoint and URIs. Then you could try out some of the Examples first before trying this pattern out.

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

Unsubscribe or edit your notifications preferences