THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
| 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 move 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
...
When the DeadLetterChannel moves a message to |
...
the dead letter endpoint, then if any new exceptions is thrown during that process, then by default the dead letter channel will handle the new exception as well. This ensures that the DeadLetterChannel will always succeed. From Camel 2.15 onwards this behavior can be changed by setting the option deadLetterHandleNewException=false. Then if a new exception is thrown, then the dead letter channel will fail and propagate back that new exception (which is the behavior of the default error handler). When a new exception occurs then the dead letter channel logs this at WARN level. This can be turned off by setting logNewException=false. |
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
- delay pattern (see below for details)
- Camel 2.11: whether to allow redelivery during stopping/shutdown
Once all attempts at redelivering the message fails then the message is forwarded to the dead letter queue.
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
- delay pattern (see below for details)
- Camel 2.11: whether to allow redelivery during stopping/shutdown
Once all attempts at redelivering the message fails then the message is forwarded to the dead letter queue.
| Info |
|---|
When the DeadLetterChannel moves a message to the dead letter endpoint, then if any new exceptions is thrown during that process, then by default the dead letter channel will handle the new exception as well. This ensures that the DeadLetterChannel will always succeed. From Camel 2.15 onwards this behavior can be changed by setting the option deadLetterHandleNewException=false. Then if a new exception is thrown, then the dead letter channel will fail and propagate back that new exception (which is the behavior of the default error handler). |
About moving Exchange to dead letter queue and using handled
...