THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
Camel supports the Dead Letter Channel from the EIP patterns using the DeadLetterChannel processor which is an Error Handler.
| Tip | ||
|---|---|---|
| ||
The major difference is that Dead Letter Channel has a dead letter queue that whenever an Exchange could not be processed is moved to. It will always moved failed exchanges to this queue. Unlike the Default Error Handler that does not have a dead letter queue. So whenever an Exchange could not be processed the error is propagated back to the client. Notice: You can adjust this behavior of whether the client should be notified or not with the handled option. |
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.
...
When all attempts of redelivery have failed the Exchange is moved to the dead letter queue (the dead letter endpoint). The client exchange is then notified as the caused exception is set on the Exchange. However if you want to handle this you can set the handled to true on 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:
| Code Block | ||||
|---|---|---|---|---|
| ||||
errorHandler(deadLetterChannel("jms:queue:dead").maximumRedeliveries(3).dealyredeliverDealy(5000).handled(true));
|
The Dead Letter Channel above will clear the caused exception when the Exchange is moved to the jms:queue:dead destination and the client will not notice the failure.
By default handled is true.
How to let the client notice the error?
If you want to move the message to the dead letter queue and also let the client notice the error, then you can configure the Dead Letter Channel to not handle the error. For example:
| Code Block | ||||
|---|---|---|---|---|
| ||||
errorHandler(deadLetterChannel("jms:queue:dead").maximumRedeliveries(3).redeliverDealy(5000).handled(false));
|
When all attempts of redelivery have failed the Exchange is moved to the dead letter queue (the dead letter endpoint). As the Dead Letter Channel
is configured to not handle it, it will mark the Exchange as failed so the client will be notified of this error configured and thus its false.
| Tip | ||
|---|---|---|
| ||
See also Exception Clause for more details on the handled policy as this feature was first introduced here and thus we have more docuemntation and samples there. |
...
| Code Block | ||||
|---|---|---|---|---|
| ||||
// will use original body
errorHandler(deadLetterChannel("jms:queue:dead")
.useOriginalBody().handled(true).mamimumRedeliveries(5).delayredeliverDelay(5000);
|
Then the messages routed to the jms:queue:dead is the original input. If we want to manually retry we can move the JMS message from the failed to the input queue, with no problem as the message is the same as the original we received.
...
The default redeliver policy will use the following values:
- maximumRedeliveries=5
- delayredeliverDelay=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
- Stack traces is logged
...