Dead Letter ChannelPage edited by Claus IbsenDead Letter ChannelCamel supports the Dead Letter Channel from the EIP patterns using the DeadLetterChannel processor which is an Error Handler.
RedeliveryIt 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
Once all attempts at redelivering the message fails then the message is forwarded to the dead letter queue. About moving Exchange to dead letter queue and using handledHandled on Dead Letter Channel was introduced in Camel 2.0, this feature does not exist in Camel 1.x When all attempts of redelivery have failed the Exchange is moved to the dead letter queue (the dead letter endpoint). The exchange is then complete and from the client point of view it was processed. As such the Dead Letter Channel have handled the Exchange. For instance configuring the dead letter channel as:
errorHandler(deadLetterChannel("jms:queue:dead").maximumRedeliveries(3).redeliverDealy(5000));
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. Camel will log delivery failures at the DEBUG logging level by default. You can change this by specifying retriesExhaustedLogLevel and/or retryAttemptedLogLevel. See ExceptionBuilderWithRetryLoggingLevelSetTest for an example. In Camel 2.0 you can turn logging of stack traces on/off. If turned off Camel will still log the redelivery attempt. Its just much less verbose. Redeliver Delay PatternAvailable as of Camel 2.0 The idea is to set groups of ranges using the following syntax: limit:delay;limit 2:delay 2;limit 3:delay 3;...;limit N:delay N Each group has two values separated with colon
Lets clarify this with an example: That gives us 3 groups:
Resulting in these delays for redelivery attempt:
You can start a group with limit 0 to eg have a starting delay: delayPattern=0:1000;5:5000
There is no requirement that the next delay should be higher than the previous. You can use any delay value you like. For example with delayPattern=0:5000;3:1000 we start with 5 sec delay and then later reduce that to 1 second. Redelivery headerWhen a message is redelivered the DeadLetterChannel will append a customizable header to the message to indicate how many times its been redelivered. And a boolean flag whether it is being redelivered or not (first attempt) Which endpoint failedAvailable as of Camel 2.1 When Camel routes messages it will decorate the Exchange with a property that contains the last endpoint Camel send the Exchange to: String lastEndpointUri = exchange.getProperty(Exchange.TO_ENDPOINT, String.class); The Exchange.TO_ENDPOINT have the constant value CamelToEndpoint. This information is updated when Camel sends a message to any endpoint. So if it exists its the last endpoint which Camel send the Exchange to. When for example processing the Exchange at a given Endpoint and the message is to be moved into the dead letter queue, then Camel also decorates the Exchange with another property that contains that last endpoint: String failedEndpointUri = exchange.getProperty(Exchange.FAILURE_ENDPOINT, String.class); The Exchange.FAILURE_ENDPOINT have the constant value CamelFailureEndpoint. This allows for example you to fetch this information in your dead letter queue and use that for error reporting. Notice: These information is kept on the Exchange even if the message was successfully processed by a given endpoint, and then later fails for example in a local Bean processing instead. So beware that this is a hint that helps pinpoint errors. from("activemq:queue:foo") .to("http://someserver/somepath") .beanRef("foo"); Now suppose the route above and a failure happens in the foo bean. Then the Exchange.TO_ENDPOINT and Exchange.FAILURE_ENDPOINT will still contain the value of http://someserver/somepath. SamplesThe 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?In Camel 1.6.0 we added support directly in Dead Letter Channel to set a Processor that is executed before each redelivery attempt. When Dead Letter Channel is doing redeliver its possible to configure a Processor that is executed just before every redelivery attempt. This can be used for the situations where you need to alter the message before its redelivered. Here we configure the Dead Letter Channel to use our processor MyRedeliveryProcessor to be executed before each redelivery. // we configure our Dead Letter Channel to invoke // MyRedeliveryProcessor before a redelivery is // attempted. This allows us to alter the message before errorHandler(deadLetterChannel("mock:error").maximumRedeliveries(5) .onRedelivery(new MyRedeliverPrcessor()) // setting delay to zero is just to make unit teting faster .redeliverDelay(0L)); And this is the processor MyRedeliveryProcessor where we alter the message. // This is our processor that is executed before every redelivery attempt // here we can do what we want in the java code, such as altering the message public class MyRedeliverPrcessor implements 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("CamelRedeliveryCounter", Integer.class); exchange.getIn().setBody(body + count); } } Using This PatternIf 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.
Change Notification Preferences
View Online
|
View Change
|
Add Comment
|
- [CONF] Apache Camel > Dead Letter Channel confluence
- [CONF] Apache Camel > Dead Letter Channel confluence
- [CONF] Apache Camel > Dead Letter Channel confluence
- [CONF] Apache Camel > Dead Letter Channel confluence