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

Wed, 07 Jan 2009 08:39:32 -0800

Page Edited : CAMEL : Dead Letter Channel

Dead Letter Channel has been edited by Claus Ibsen (Jan 07, 2009).

(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() {
        // using dead letter channel with a seda queue for errors
        errorHandler(deadLetterChannel("seda:errors"));

        // here is our route
        from("seda:a").to("seda:b");
    }
};

You can also configure the RedeliveryPolicy as this example shows

RouteBuilder builder = new RouteBuilder() {
    public void configure() {
        // configures dead letter channel to use seda queue for errors and use at most 2 redelveries
        // and exponential backoff
        errorHandler(deadLetterChannel("seda:errors").maximumRedeliveries(2).useExponentialBackOff());

        // here is our route
        from("seda:a").to("seda:b");
    }
};

How can I modify the Exchange before redelivery?

When Dead Letter Channel is doing redeliver it redeliveries immediately with the original Exchange that caused the error in the first place. However in some situations you might want to be able to alter the message before its redelivered. As Camel at this time of writing doesn't have a nice DSL syntax or configuration on the Dead Letter Channel to allow custom processing before redeliver we are gonna show a different solution, that actually also pin points the flexibility Camel has.

We are going to use an interceptor that gets triggered when an Exchange is being redelivered. We use the fact that interceptors by default will proceed from the point of interceptor. This is the Detour EIP pattern we are using.

The code below demonstrates this.

// we configure an interceptor that is triggered when the redelivery flag
// has been set on an exchange
intercept().when(header("org.apache.camel.Redelivered").isNotNull()).
        process(new Processor() {
            public void process(Exchange exchange) throws Exception {
                // the message is being redelivered so we can alter it

                // we just append the redelivery counter to the body
                // you can of course do all kind of stuff instead
                String body = exchange.getIn().getBody(String.class);
                int count = exchange.getIn().getHeader("org.apache.camel.RedeliveryCounter", Integer.class);

                exchange.getIn().setBody(body + count);
            }
        });

However you should notice as Camel will keep the redeliver flag on the Exchange for the remainder of its routing this interceptor will kick in for subsequence processing. So you should keep track if you already have altered the message before redelivery.

We are working on providing better out-of-the-box support for this in a future Camel release.

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

Reply via email to