Author: buildbot
Date: Sun May 10 11:20:11 2015
New Revision: 950812
Log:
Production update by buildbot for camel
Modified:
websites/production/camel/content/book-in-one-page.html
websites/production/camel/content/book-pattern-appendix.html
websites/production/camel/content/cache/main.pageCache
websites/production/camel/content/dead-letter-channel.html
Modified: websites/production/camel/content/book-in-one-page.html
==============================================================================
--- websites/production/camel/content/book-in-one-page.html (original)
+++ websites/production/camel/content/book-in-one-page.html Sun May 10 11:20:11
2015
@@ -4040,11 +4040,11 @@ While not actual tutorials you might fin
</div>
</div>
<h2 id="BookInOnePage-Preface">Preface</h2><p>This tutorial aims to guide the
reader through the stages of creating a project which uses Camel to facilitate
the routing of messages from a JMS queue to a <a shape="rect"
class="external-link" href="http://www.springramework.org";
rel="nofollow">Spring</a> service. The route works in a synchronous fashion
returning a response to the client.</p><p><style type="text/css">/*<![CDATA[*/
-div.rbtoc1431141786647 {padding: 0px;}
-div.rbtoc1431141786647 ul {list-style: disc;margin-left: 0px;}
-div.rbtoc1431141786647 li {margin-left: 0px;padding-left: 0px;}
+div.rbtoc1431256729047 {padding: 0px;}
+div.rbtoc1431256729047 ul {list-style: disc;margin-left: 0px;}
+div.rbtoc1431256729047 li {margin-left: 0px;padding-left: 0px;}
-/*]]>*/</style></p><div class="toc-macro rbtoc1431141786647">
+/*]]>*/</style></p><div class="toc-macro rbtoc1431256729047">
<ul class="toc-indentation"><li><a shape="rect"
href="#Tutorial-JmsRemoting-TutorialonSpringRemotingwithJMS">Tutorial on Spring
Remoting with JMS</a></li><li><a shape="rect"
href="#Tutorial-JmsRemoting-Preface">Preface</a></li><li><a shape="rect"
href="#Tutorial-JmsRemoting-Prerequisites">Prerequisites</a></li><li><a
shape="rect"
href="#Tutorial-JmsRemoting-Distribution">Distribution</a></li><li><a
shape="rect" href="#Tutorial-JmsRemoting-About">About</a></li><li><a
shape="rect" href="#Tutorial-JmsRemoting-CreatetheCamelProject">Create the
Camel Project</a>
<ul class="toc-indentation"><li><a shape="rect"
href="#Tutorial-JmsRemoting-UpdatethePOMwithDependencies">Update the POM with
Dependencies</a></li></ul>
</li><li><a shape="rect" href="#Tutorial-JmsRemoting-WritingtheServer">Writing
the Server</a>
@@ -6230,11 +6230,11 @@ So we completed the last piece in the pi
<style type="text/css">/*<![CDATA[*/
-div.rbtoc1431141786872 {padding: 0px;}
-div.rbtoc1431141786872 ul {list-style: disc;margin-left: 0px;}
-div.rbtoc1431141786872 li {margin-left: 0px;padding-left: 0px;}
+div.rbtoc1431256729304 {padding: 0px;}
+div.rbtoc1431256729304 ul {list-style: disc;margin-left: 0px;}
+div.rbtoc1431256729304 li {margin-left: 0px;padding-left: 0px;}
-/*]]>*/</style><div class="toc-macro rbtoc1431141786872">
+/*]]>*/</style><div class="toc-macro rbtoc1431256729304">
<ul class="toc-indentation"><li><a shape="rect"
href="#Tutorial-AXIS-Camel-TutorialusingAxis1.4withApacheCamel">Tutorial using
Axis 1.4 with Apache Camel</a>
<ul class="toc-indentation"><li><a shape="rect"
href="#Tutorial-AXIS-Camel-Prerequisites">Prerequisites</a></li><li><a
shape="rect"
href="#Tutorial-AXIS-Camel-Distribution">Distribution</a></li><li><a
shape="rect"
href="#Tutorial-AXIS-Camel-Introduction">Introduction</a></li><li><a
shape="rect" href="#Tutorial-AXIS-Camel-SettinguptheprojecttorunAxis">Setting
up the project to run Axis</a>
<ul class="toc-indentation"><li><a shape="rect"
href="#Tutorial-AXIS-Camel-Maven2">Maven 2</a></li><li><a shape="rect"
href="#Tutorial-AXIS-Camel-wsdl">wsdl</a></li><li><a shape="rect"
href="#Tutorial-AXIS-Camel-ConfiguringAxis">Configuring Axis</a></li><li><a
shape="rect" href="#Tutorial-AXIS-Camel-RunningtheExample">Running the
Example</a></li></ul>
@@ -13018,7 +13018,7 @@ RouteBuilder builder = new RouteBuilder(
<p class="title">Difference between Dead Letter Channel
and Default Error Handler</p>
<span class="aui-icon icon-success">Icon</span>
<div class="message-content">
- <p>The Default Error Handler does very little: it
ends the Exchange immediately and propagates the thrown Exception back to the
caller.</p><p>The Dead Letter Channel lets you control behaviors including
redelivery, whether to propagate the thrown Exception to the caller (the
<strong>handled</strong> option), and where the (failed) Exchange should now be
routed to.</p><p>When the DeadLetterChannel moves a message to the dead letter
endpoint, any new Exception thrown is by default handled by the dead letter
channel as well. This ensures that the DeadLetterChannel will always succeed.
From <strong>Camel 2.15</strong> 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.</p>
+ <p>The Default Error Handler does very little: it
ends the Exchange immediately and propagates the thrown Exception back to the
caller.</p><p>The Dead Letter Channel lets you control behaviors including
redelivery, whether to propagate the thrown Exception to the caller (the
<strong>handled</strong> option), and where the (failed) Exchange should now be
routed to.</p><p>The Dead Letter Channel is also by default configured to not
be verbose in the logs, so when a message is handled and moved to the dead
letter endpoint, then there is nothing logged. If you want some level of
logging you can use the various options on the redelivery policy / dead letter
channel to configure this. For example if you want the message history then set
logExhaustedMessageHistory=true (and logHandled=true for Camel 2.15.x or
older).</p><p>When the DeadLetterChannel moves a message to the dead letter
endpoint, any new Exception thrown is by default handled by the dead letter cha
nnel as well. This ensures that the DeadLetterChannel will always succeed.
From <strong>Camel 2.15</strong> 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.</p>
</div>
</div>
<h3 id="BookInOnePage-Redelivery">Redelivery</h3><p>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.</p><p>The <a shape="rect" class="external-link"
href="http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/processor/RedeliveryPolicy.html";>RedeliveryPolicy</a>
defines how the message is to be redelivered. You can customize things
like</p><ul><li>how many times a message is attempted to be redelivered before
it is considered a failure and sent to the dead letter channel</li><li>the
initial redelivery timeout</li><li>whether or not exponential backoff is used
(i.e. the time between retries increases using a backoff
multiplier)</li><li>whether to use collision avo
idance to add some randomness to the timings</li><li>delay pattern (see below
for details)</li><li><strong>Camel 2.11:</strong> whether to allow redelivery
during stopping/shutdown</li></ul><p>Once all attempts at redelivering the
message fails then the message is forwarded to the dead letter queue.</p><h3
id="BookInOnePage-AboutmovingExchangetodeadletterqueueandusinghandled">About
moving Exchange to dead letter queue and using
handled</h3><p><strong>Handled</strong> on <a shape="rect"
href="dead-letter-channel.html">Dead Letter Channel</a></p><p>When all attempts
of redelivery have failed the <a shape="rect" href="exchange.html">Exchange</a>
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
<a shape="rect" href="dead-letter-channel.html">Dead Letter Channel</a> have
handled the <a shape="rect" href="exchange.html">Exchange</a>.</p><p>For
instance configuring the dead letter cha
nnel as:</p><p><strong>Using the <a shape="rect"
href="fluent-builders.html">Fluent Builders</a></strong></p><div class="code
panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
@@ -13059,7 +13059,7 @@ RouteBuilder builder = new RouteBuilder(
<p>We also support for per <a shape="rect"
href="exception-clause.html"><strong>onException</strong></a> to set a
<strong>onRedeliver</strong>. That means you can do special on redelivery for
different exceptions, as opposed to onRedelivery set on <a shape="rect"
href="dead-letter-channel.html">Dead Letter Channel</a> can be viewed as a
global scope.</p>
</div>
</div>
-<h3 id="BookInOnePage-Redeliverydefaultvalues">Redelivery default
values</h3><p>Redelivery is disabled by default.</p><p>The default redeliver
policy will use the following
values:</p><ul><li>maximumRedeliveries=0</li><li>redeliverDelay=1000L (1
second)</li><li>maximumRedeliveryDelay = 60 * 1000L (60 seconds)</li><li>And
the exponential backoff and collision avoidance is turned off.</li><li>The
retriesExhaustedLogLevel are set to LoggingLevel.ERROR</li><li>The
retryAttemptedLogLevel are set to LoggingLevel.DEBUG</li><li>Stack traces is
logged for exhausted messages from Camel 2.2 onwards.</li><li>Handled
exceptions is not logged from Camel 2.3 onwards</li></ul><p>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.</p><p>The
maximum redeliveries is the number of <strong>re</strong> delivery attempts. By
default Camel will try to process the exchange 1 + 5 times. 1 time for the norma
l attempt and then 5 attempts as redeliveries.<br clear="none"> Setting the
maximumRedeliveries to a negative value such as -1 will then always redelivery
(unlimited).<br clear="none"> Setting the maximumRedeliveries to 0 will disable
any re delivery attempt.</p><p>Camel will log delivery failures at the DEBUG
logging level by default. You can change this by specifying
retriesExhaustedLogLevel and/or retryAttemptedLogLevel. See <a shape="rect"
class="external-link"
href="http://svn.apache.org/repos/asf/camel/trunk/camel-core/src/test/java/org/apache/camel/builder/ExceptionBuilderWithRetryLoggingLevelSetTest.java";>ExceptionBuilderWithRetryLoggingLevelSetTest</a>
for an example.</p><p>You can turn logging of stack traces on/off. If turned
off Camel will still log the redelivery attempt. Its just much less
verbose.</p><h4 id="BookInOnePage-RedeliverDelayPattern">Redeliver Delay
Pattern</h4><p>Delay pattern is used as a single option to set a range pattern
for delays. If used then the f
ollowing options does not apply: (delay, backOffMultiplier,
useExponentialBackOff, useCollisionAvoidance,
maximumRedeliveryDelay).</p><p>The idea is to set groups of ranges using the
following syntax: <code>limit:delay;limit 2:delay 2;limit 3:delay 3;...;limit
N:delay N</code></p><p>Each group has two values separated with colon</p><ul
class="alternate"><li>limit = upper limit</li><li>delay = delay in millis<br
clear="none"> And the groups is again separated with semi colon.<br
clear="none"> The rule of thumb is that the next groups should have a higher
limit than the previous group.</li></ul><p>Lets clarify this with an
example:<br clear="none">
<code>delayPattern=5:1000;10:5000;20:20000</code></p><p>That gives us 3
groups:</p><ul
class="alternate"><li>5:1000</li><li>10:5000</li><li>20:20000</li></ul><p>Resulting
in these delays for redelivery attempt:</p><ul
class="alternate"><li>Redelivery attempt number 1..4 = 0 millis (as the first
group start with 5)</li><li>Redelivery attempt
number 5..9 = 1000 millis (the first group)</li><li>Redelivery attempt number
10..19 = 5000 millis (the second group)</li><li>Redelivery attempt number 20..
= 20000 millis (the last group)</li></ul><p>Note: The first redelivery attempt
is 1, so the first group should start with 1 or higher.</p><p>You can start a
group with limit 1 to eg have a starting delay:
<code>delayPattern=1:1000;5:5000</code></p><ul class="alternate"><li>Redelivery
attempt number 1..4 = 1000 millis (the first group)</li><li>Redelivery attempt
number 5.. = 5000 millis (the last group)</li></ul><p>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 <code>delayPattern=1:5000;3:1000</code> we
start with 5 sec delay and then later reduce that to 1 second.</p><h3
id="BookInOnePage-Redeliveryheader">Redelivery header</h3><p>When a message is
redelivered the <a shape="rect" class="external-link"
href="http://camel.apache.org/maven/came
l-core/apidocs/org/apache/camel/processor/DeadLetterChannel.html">DeadLetterChannel</a>
will append a customizable header to the message to indicate how many times
its been redelivered. <br clear="none"> Before Camel 2.6: The header is
<strong>CamelRedeliveryCounter</strong>, which is also defined on the
<code>Exchange.REDELIVERY_COUNTER</code>.<br clear="none"> Starting with 2.6:
The header <strong>CamelRedeliveryMaxCounter</strong>, which is also defined on
the <code>Exchange.REDELIVERY_MAX_COUNTER</code>, contains the maximum
redelivery setting. This header is absent if you use <code>retryWhile</code> or
have unlimited maximum redelivery configured.</p><p>And a boolean flag whether
it is being redelivered or not (first attempt)<br clear="none"> The header
<strong>CamelRedelivered</strong> contains a boolean if the message is
redelivered or not, which is also defined on the
<code>Exchange.REDELIVERED</code>.</p><p>Dynamically calculated delay from the
exchange<br clear="none"> In
Camel 2.9 and 2.8.2: The header is <strong>CamelRedeliveryDelay</strong>,
which is also defined on the <code>Exchange.REDELIVERY_DELAY</code>.<br
clear="none"> Is this header is absent, normal redelivery rules apply.</p><h4
id="BookInOnePage-Whichendpointfailed">Which endpoint
failed</h4><p><strong>Available as of Camel 2.1</strong></p><p>When Camel
routes messages it will decorate the <a shape="rect"
href="exchange.html">Exchange</a> with a property that contains the
<strong>last</strong> endpoint Camel send the <a shape="rect"
href="exchange.html">Exchange</a> to:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<h3 id="BookInOnePage-Redeliverydefaultvalues">Redelivery default
values</h3><p>Redelivery is disabled by default.</p><p>The default redeliver
policy will use the following
values:</p><ul><li>maximumRedeliveries=0</li><li>redeliverDelay=1000L (1
second)</li><li>maximumRedeliveryDelay = 60 * 1000L (60 seconds)</li><li>And
the exponential backoff and collision avoidance is turned off.</li><li>The
retriesExhaustedLogLevel are set to LoggingLevel.ERROR</li><li>The
retryAttemptedLogLevel are set to LoggingLevel.DEBUG</li><li>Stack traces is
logged for exhausted messages from Camel 2.2 onwards.</li><li>Handled
exceptions is not logged from Camel 2.3
onwards</li><li>logExhaustedMessageHistory is true for default error handler,
and false for dead letter channel.</li></ul><p>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.</p><p>The maximum redeliveries
is the number of <strong>re</stron
g> 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.<br
clear="none"> Setting the maximumRedeliveries to a negative value such as -1
will then always redelivery (unlimited).<br clear="none"> Setting the
maximumRedeliveries to 0 will disable any re delivery attempt.</p><p>Camel will
log delivery failures at the DEBUG logging level by default. You can change
this by specifying retriesExhaustedLogLevel and/or retryAttemptedLogLevel. See
<a shape="rect" class="external-link"
href="http://svn.apache.org/repos/asf/camel/trunk/camel-core/src/test/java/org/apache/camel/builder/ExceptionBuilderWithRetryLoggingLevelSetTest.java";>ExceptionBuilderWithRetryLoggingLevelSetTest</a>
for an example.</p><p>You can turn logging of stack traces on/off. If turned
off Camel will still log the redelivery attempt. Its just much less
verbose.</p><h4 id="BookInOnePage-RedeliverDelayPattern">Redeliver Delay Patt
ern</h4><p>Delay pattern is used as a single option to set a range pattern for
delays. If used then the following options does not apply: (delay,
backOffMultiplier, useExponentialBackOff, useCollisionAvoidance,
maximumRedeliveryDelay).</p><p>The idea is to set groups of ranges using the
following syntax: <code>limit:delay;limit 2:delay 2;limit 3:delay 3;...;limit
N:delay N</code></p><p>Each group has two values separated with colon</p><ul
class="alternate"><li>limit = upper limit</li><li>delay = delay in millis<br
clear="none"> And the groups is again separated with semi colon.<br
clear="none"> The rule of thumb is that the next groups should have a higher
limit than the previous group.</li></ul><p>Lets clarify this with an
example:<br clear="none">
<code>delayPattern=5:1000;10:5000;20:20000</code></p><p>That gives us 3
groups:</p><ul
class="alternate"><li>5:1000</li><li>10:5000</li><li>20:20000</li></ul><p>Resulting
in these delays for redelivery attempt:</p><ul class="alternate"><
li>Redelivery attempt number 1..4 = 0 millis (as the first group start with
5)</li><li>Redelivery attempt number 5..9 = 1000 millis (the first
group)</li><li>Redelivery attempt number 10..19 = 5000 millis (the second
group)</li><li>Redelivery attempt number 20.. = 20000 millis (the last
group)</li></ul><p>Note: The first redelivery attempt is 1, so the first group
should start with 1 or higher.</p><p>You can start a group with limit 1 to eg
have a starting delay: <code>delayPattern=1:1000;5:5000</code></p><ul
class="alternate"><li>Redelivery attempt number 1..4 = 1000 millis (the first
group)</li><li>Redelivery attempt number 5.. = 5000 millis (the last
group)</li></ul><p>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
<code>delayPattern=1:5000;3:1000</code> we start with 5 sec delay and then
later reduce that to 1 second.</p><h3
id="BookInOnePage-Redeliveryheader">Redelivery header</h3><p>When a
message is redelivered the <a shape="rect" class="external-link"
href="http://camel.apache.org/maven/camel-core/apidocs/org/apache/camel/processor/DeadLetterChannel.html";>DeadLetterChannel</a>
will append a customizable header to the message to indicate how many times
its been redelivered. <br clear="none"> Before Camel 2.6: The header is
<strong>CamelRedeliveryCounter</strong>, which is also defined on the
<code>Exchange.REDELIVERY_COUNTER</code>.<br clear="none"> Starting with 2.6:
The header <strong>CamelRedeliveryMaxCounter</strong>, which is also defined on
the <code>Exchange.REDELIVERY_MAX_COUNTER</code>, contains the maximum
redelivery setting. This header is absent if you use <code>retryWhile</code> or
have unlimited maximum redelivery configured.</p><p>And a boolean flag whether
it is being redelivered or not (first attempt)<br clear="none"> The header
<strong>CamelRedelivered</strong> contains a boolean if the message is
redelivered or not, which is also defined on the <co
de>Exchange.REDELIVERED</code>.</p><p>Dynamically calculated delay from the
exchange<br clear="none"> In Camel 2.9 and 2.8.2: The header is
<strong>CamelRedeliveryDelay</strong>, which is also defined on the
<code>Exchange.REDELIVERY_DELAY</code>.<br clear="none"> Is this header is
absent, normal redelivery rules apply.</p><h4
id="BookInOnePage-Whichendpointfailed">Which endpoint
failed</h4><p><strong>Available as of Camel 2.1</strong></p><p>When Camel
routes messages it will decorate the <a shape="rect"
href="exchange.html">Exchange</a> with a property that contains the
<strong>last</strong> endpoint Camel send the <a shape="rect"
href="exchange.html">Exchange</a> to:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[String lastEndpointUri =
exchange.getProperty(Exchange.TO_ENDPOINT, String.class);
]]></script>
</div></div><p>The <code>Exchange.TO_ENDPOINT</code> have the constant value
<code>CamelToEndpoint</code>.</p><p>This information is updated when Camel
sends a message to any endpoint. So if it exists its the <strong>last</strong>
endpoint which Camel send the Exchange to.</p><p>When for example processing
the <a shape="rect" href="exchange.html">Exchange</a> at a given <a
shape="rect" href="endpoint.html">Endpoint</a> and the message is to be moved
into the dead letter queue, then Camel also decorates the Exchange with another
property that contains that <strong>last</strong> endpoint:</p><div class="code
panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
@@ -18817,11 +18817,11 @@ template.send("direct:alias-verify&
</div>
</div>
<p>The <strong>cxf:</strong> component provides integration with <a
shape="rect" href="http://cxf.apache.org";>Apache CXF</a> for connecting to
JAX-WS services hosted in CXF.</p><p><style type="text/css">/*<![CDATA[*/
-div.rbtoc1431141798043 {padding: 0px;}
-div.rbtoc1431141798043 ul {list-style: disc;margin-left: 0px;}
-div.rbtoc1431141798043 li {margin-left: 0px;padding-left: 0px;}
+div.rbtoc1431256740307 {padding: 0px;}
+div.rbtoc1431256740307 ul {list-style: disc;margin-left: 0px;}
+div.rbtoc1431256740307 li {margin-left: 0px;padding-left: 0px;}
-/*]]>*/</style></p><div class="toc-macro rbtoc1431141798043">
+/*]]>*/</style></p><div class="toc-macro rbtoc1431256740307">
<ul class="toc-indentation"><li><a shape="rect" href="#CXF-CXFComponent">CXF
Component</a>
<ul class="toc-indentation"><li><a shape="rect" href="#CXF-URIformat">URI
format</a></li><li><a shape="rect" href="#CXF-Options">Options</a>
<ul class="toc-indentation"><li><a shape="rect"
href="#CXF-Thedescriptionsofthedataformats">The descriptions of the
dataformats</a>
Modified: websites/production/camel/content/book-pattern-appendix.html
==============================================================================
--- websites/production/camel/content/book-pattern-appendix.html (original)
+++ websites/production/camel/content/book-pattern-appendix.html Sun May 10
11:20:11 2015
@@ -452,7 +452,7 @@ RouteBuilder builder = new RouteBuilder(
<p class="title">Difference between Dead Letter Channel
and Default Error Handler</p>
<span class="aui-icon icon-success">Icon</span>
<div class="message-content">
- <p>The Default Error Handler does very little: it
ends the Exchange immediately and propagates the thrown Exception back to the
caller.</p><p>The Dead Letter Channel lets you control behaviors including
redelivery, whether to propagate the thrown Exception to the caller (the
<strong>handled</strong> option), and where the (failed) Exchange should now be
routed to.</p><p>When the DeadLetterChannel moves a message to the dead letter
endpoint, any new Exception thrown is by default handled by the dead letter
channel as well. This ensures that the DeadLetterChannel will always succeed.
From <strong>Camel 2.15</strong> 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.</p>
+ <p>The Default Error Handler does very little: it
ends the Exchange immediately and propagates the thrown Exception back to the
caller.</p><p>The Dead Letter Channel lets you control behaviors including
redelivery, whether to propagate the thrown Exception to the caller (the
<strong>handled</strong> option), and where the (failed) Exchange should now be
routed to.</p><p>The Dead Letter Channel is also by default configured to not
be verbose in the logs, so when a message is handled and moved to the dead
letter endpoint, then there is nothing logged. If you want some level of
logging you can use the various options on the redelivery policy / dead letter
channel to configure this. For example if you want the message history then set
logExhaustedMessageHistory=true (and logHandled=true for Camel 2.15.x or
older).</p><p>When the DeadLetterChannel moves a message to the dead letter
endpoint, any new Exception thrown is by default handled by the dead letter cha
nnel as well. This ensures that the DeadLetterChannel will always succeed.
From <strong>Camel 2.15</strong> 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.</p>
</div>
</div>
<h3 id="BookPatternAppendix-Redelivery">Redelivery</h3><p>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.</p><p>The <a shape="rect" class="external-link"
href="http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/processor/RedeliveryPolicy.html";>RedeliveryPolicy</a>
defines how the message is to be redelivered. You can customize things
like</p><ul><li>how many times a message is attempted to be redelivered before
it is considered a failure and sent to the dead letter channel</li><li>the
initial redelivery timeout</li><li>whether or not exponential backoff is used
(i.e. the time between retries increases using a backoff
multiplier)</li><li>whether to use collisi
on avoidance to add some randomness to the timings</li><li>delay pattern (see
below for details)</li><li><strong>Camel 2.11:</strong> whether to allow
redelivery during stopping/shutdown</li></ul><p>Once all attempts at
redelivering the message fails then the message is forwarded to the dead letter
queue.</p><h3
id="BookPatternAppendix-AboutmovingExchangetodeadletterqueueandusinghandled">About
moving Exchange to dead letter queue and using
handled</h3><p><strong>Handled</strong> on <a shape="rect"
href="dead-letter-channel.html">Dead Letter Channel</a></p><p>When all attempts
of redelivery have failed the <a shape="rect" href="exchange.html">Exchange</a>
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
<a shape="rect" href="dead-letter-channel.html">Dead Letter Channel</a> have
handled the <a shape="rect" href="exchange.html">Exchange</a>.</p><p>For
instance configuring the dea
d letter channel as:</p><p><strong>Using the <a shape="rect"
href="fluent-builders.html">Fluent Builders</a></strong></p><div class="code
panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
@@ -493,7 +493,7 @@ RouteBuilder builder = new RouteBuilder(
<p>We also support for per <a shape="rect"
href="exception-clause.html"><strong>onException</strong></a> to set a
<strong>onRedeliver</strong>. That means you can do special on redelivery for
different exceptions, as opposed to onRedelivery set on <a shape="rect"
href="dead-letter-channel.html">Dead Letter Channel</a> can be viewed as a
global scope.</p>
</div>
</div>
-<h3 id="BookPatternAppendix-Redeliverydefaultvalues">Redelivery default
values</h3><p>Redelivery is disabled by default.</p><p>The default redeliver
policy will use the following
values:</p><ul><li>maximumRedeliveries=0</li><li>redeliverDelay=1000L (1
second)</li><li>maximumRedeliveryDelay = 60 * 1000L (60 seconds)</li><li>And
the exponential backoff and collision avoidance is turned off.</li><li>The
retriesExhaustedLogLevel are set to LoggingLevel.ERROR</li><li>The
retryAttemptedLogLevel are set to LoggingLevel.DEBUG</li><li>Stack traces is
logged for exhausted messages from Camel 2.2 onwards.</li><li>Handled
exceptions is not logged from Camel 2.3 onwards</li></ul><p>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.</p><p>The
maximum redeliveries is the number of <strong>re</strong> 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.<br clear="none"> Setting
the maximumRedeliveries to a negative value such as -1 will then always
redelivery (unlimited).<br clear="none"> Setting the maximumRedeliveries to 0
will disable any re delivery attempt.</p><p>Camel will log delivery failures at
the DEBUG logging level by default. You can change this by specifying
retriesExhaustedLogLevel and/or retryAttemptedLogLevel. See <a shape="rect"
class="external-link"
href="http://svn.apache.org/repos/asf/camel/trunk/camel-core/src/test/java/org/apache/camel/builder/ExceptionBuilderWithRetryLoggingLevelSetTest.java";>ExceptionBuilderWithRetryLoggingLevelSetTest</a>
for an example.</p><p>You can turn logging of stack traces on/off. If turned
off Camel will still log the redelivery attempt. Its just much less
verbose.</p><h4 id="BookPatternAppendix-RedeliverDelayPattern">Redeliver Delay
Pattern</h4><p>Delay pattern is used as a single option to set a range pattern
for delays. If use
d then the following options does not apply: (delay, backOffMultiplier,
useExponentialBackOff, useCollisionAvoidance,
maximumRedeliveryDelay).</p><p>The idea is to set groups of ranges using the
following syntax: <code>limit:delay;limit 2:delay 2;limit 3:delay 3;...;limit
N:delay N</code></p><p>Each group has two values separated with colon</p><ul
class="alternate"><li>limit = upper limit</li><li>delay = delay in millis<br
clear="none"> And the groups is again separated with semi colon.<br
clear="none"> The rule of thumb is that the next groups should have a higher
limit than the previous group.</li></ul><p>Lets clarify this with an
example:<br clear="none">
<code>delayPattern=5:1000;10:5000;20:20000</code></p><p>That gives us 3
groups:</p><ul
class="alternate"><li>5:1000</li><li>10:5000</li><li>20:20000</li></ul><p>Resulting
in these delays for redelivery attempt:</p><ul
class="alternate"><li>Redelivery attempt number 1..4 = 0 millis (as the first
group start with 5)</li><li>Redeli
very attempt number 5..9 = 1000 millis (the first group)</li><li>Redelivery
attempt number 10..19 = 5000 millis (the second group)</li><li>Redelivery
attempt number 20.. = 20000 millis (the last group)</li></ul><p>Note: The first
redelivery attempt is 1, so the first group should start with 1 or
higher.</p><p>You can start a group with limit 1 to eg have a starting delay:
<code>delayPattern=1:1000;5:5000</code></p><ul class="alternate"><li>Redelivery
attempt number 1..4 = 1000 millis (the first group)</li><li>Redelivery attempt
number 5.. = 5000 millis (the last group)</li></ul><p>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 <code>delayPattern=1:5000;3:1000</code> we
start with 5 sec delay and then later reduce that to 1 second.</p><h3
id="BookPatternAppendix-Redeliveryheader">Redelivery header</h3><p>When a
message is redelivered the <a shape="rect" class="external-link"
href="http://camel.apa
che.org/maven/camel-core/apidocs/org/apache/camel/processor/DeadLetterChannel.html">DeadLetterChannel</a>
will append a customizable header to the message to indicate how many times
its been redelivered. <br clear="none"> Before Camel 2.6: The header is
<strong>CamelRedeliveryCounter</strong>, which is also defined on the
<code>Exchange.REDELIVERY_COUNTER</code>.<br clear="none"> Starting with 2.6:
The header <strong>CamelRedeliveryMaxCounter</strong>, which is also defined on
the <code>Exchange.REDELIVERY_MAX_COUNTER</code>, contains the maximum
redelivery setting. This header is absent if you use <code>retryWhile</code> or
have unlimited maximum redelivery configured.</p><p>And a boolean flag whether
it is being redelivered or not (first attempt)<br clear="none"> The header
<strong>CamelRedelivered</strong> contains a boolean if the message is
redelivered or not, which is also defined on the
<code>Exchange.REDELIVERED</code>.</p><p>Dynamically calculated delay from the
exchange<br
clear="none"> In Camel 2.9 and 2.8.2: The header is
<strong>CamelRedeliveryDelay</strong>, which is also defined on the
<code>Exchange.REDELIVERY_DELAY</code>.<br clear="none"> Is this header is
absent, normal redelivery rules apply.</p><h4
id="BookPatternAppendix-Whichendpointfailed">Which endpoint
failed</h4><p><strong>Available as of Camel 2.1</strong></p><p>When Camel
routes messages it will decorate the <a shape="rect"
href="exchange.html">Exchange</a> with a property that contains the
<strong>last</strong> endpoint Camel send the <a shape="rect"
href="exchange.html">Exchange</a> to:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<h3 id="BookPatternAppendix-Redeliverydefaultvalues">Redelivery default
values</h3><p>Redelivery is disabled by default.</p><p>The default redeliver
policy will use the following
values:</p><ul><li>maximumRedeliveries=0</li><li>redeliverDelay=1000L (1
second)</li><li>maximumRedeliveryDelay = 60 * 1000L (60 seconds)</li><li>And
the exponential backoff and collision avoidance is turned off.</li><li>The
retriesExhaustedLogLevel are set to LoggingLevel.ERROR</li><li>The
retryAttemptedLogLevel are set to LoggingLevel.DEBUG</li><li>Stack traces is
logged for exhausted messages from Camel 2.2 onwards.</li><li>Handled
exceptions is not logged from Camel 2.3
onwards</li><li>logExhaustedMessageHistory is true for default error handler,
and false for dead letter channel.</li></ul><p>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.</p><p>The maximum redeliveries
is the number of <strong>re<
/strong> 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.<br clear="none"> Setting the maximumRedeliveries to a negative
value such as -1 will then always redelivery (unlimited).<br clear="none">
Setting the maximumRedeliveries to 0 will disable any re delivery
attempt.</p><p>Camel will log delivery failures at the DEBUG logging level by
default. You can change this by specifying retriesExhaustedLogLevel and/or
retryAttemptedLogLevel. See <a shape="rect" class="external-link"
href="http://svn.apache.org/repos/asf/camel/trunk/camel-core/src/test/java/org/apache/camel/builder/ExceptionBuilderWithRetryLoggingLevelSetTest.java";>ExceptionBuilderWithRetryLoggingLevelSetTest</a>
for an example.</p><p>You can turn logging of stack traces on/off. If turned
off Camel will still log the redelivery attempt. Its just much less
verbose.</p><h4 id="BookPatternAppendix-RedeliverDelayPattern">Redelive
r Delay Pattern</h4><p>Delay pattern is used as a single option to set a range
pattern for delays. If used then the following options does not apply: (delay,
backOffMultiplier, useExponentialBackOff, useCollisionAvoidance,
maximumRedeliveryDelay).</p><p>The idea is to set groups of ranges using the
following syntax: <code>limit:delay;limit 2:delay 2;limit 3:delay 3;...;limit
N:delay N</code></p><p>Each group has two values separated with colon</p><ul
class="alternate"><li>limit = upper limit</li><li>delay = delay in millis<br
clear="none"> And the groups is again separated with semi colon.<br
clear="none"> The rule of thumb is that the next groups should have a higher
limit than the previous group.</li></ul><p>Lets clarify this with an
example:<br clear="none">
<code>delayPattern=5:1000;10:5000;20:20000</code></p><p>That gives us 3
groups:</p><ul
class="alternate"><li>5:1000</li><li>10:5000</li><li>20:20000</li></ul><p>Resulting
in these delays for redelivery attempt:</p><ul class="
alternate"><li>Redelivery attempt number 1..4 = 0 millis (as the first group
start with 5)</li><li>Redelivery attempt number 5..9 = 1000 millis (the first
group)</li><li>Redelivery attempt number 10..19 = 5000 millis (the second
group)</li><li>Redelivery attempt number 20.. = 20000 millis (the last
group)</li></ul><p>Note: The first redelivery attempt is 1, so the first group
should start with 1 or higher.</p><p>You can start a group with limit 1 to eg
have a starting delay: <code>delayPattern=1:1000;5:5000</code></p><ul
class="alternate"><li>Redelivery attempt number 1..4 = 1000 millis (the first
group)</li><li>Redelivery attempt number 5.. = 5000 millis (the last
group)</li></ul><p>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
<code>delayPattern=1:5000;3:1000</code> we start with 5 sec delay and then
later reduce that to 1 second.</p><h3
id="BookPatternAppendix-Redeliveryheader">Redelivery hea
der</h3><p>When a message is redelivered the <a shape="rect"
class="external-link"
href="http://camel.apache.org/maven/camel-core/apidocs/org/apache/camel/processor/DeadLetterChannel.html";>DeadLetterChannel</a>
will append a customizable header to the message to indicate how many times
its been redelivered. <br clear="none"> Before Camel 2.6: The header is
<strong>CamelRedeliveryCounter</strong>, which is also defined on the
<code>Exchange.REDELIVERY_COUNTER</code>.<br clear="none"> Starting with 2.6:
The header <strong>CamelRedeliveryMaxCounter</strong>, which is also defined on
the <code>Exchange.REDELIVERY_MAX_COUNTER</code>, contains the maximum
redelivery setting. This header is absent if you use <code>retryWhile</code> or
have unlimited maximum redelivery configured.</p><p>And a boolean flag whether
it is being redelivered or not (first attempt)<br clear="none"> The header
<strong>CamelRedelivered</strong> contains a boolean if the message is
redelivered or not, which is also
defined on the <code>Exchange.REDELIVERED</code>.</p><p>Dynamically calculated
delay from the exchange<br clear="none"> In Camel 2.9 and 2.8.2: The header is
<strong>CamelRedeliveryDelay</strong>, which is also defined on the
<code>Exchange.REDELIVERY_DELAY</code>.<br clear="none"> Is this header is
absent, normal redelivery rules apply.</p><h4
id="BookPatternAppendix-Whichendpointfailed">Which endpoint
failed</h4><p><strong>Available as of Camel 2.1</strong></p><p>When Camel
routes messages it will decorate the <a shape="rect"
href="exchange.html">Exchange</a> with a property that contains the
<strong>last</strong> endpoint Camel send the <a shape="rect"
href="exchange.html">Exchange</a> to:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[String lastEndpointUri =
exchange.getProperty(Exchange.TO_ENDPOINT, String.class);
]]></script>
</div></div><p>The <code>Exchange.TO_ENDPOINT</code> have the constant value
<code>CamelToEndpoint</code>.</p><p>This information is updated when Camel
sends a message to any endpoint. So if it exists its the <strong>last</strong>
endpoint which Camel send the Exchange to.</p><p>When for example processing
the <a shape="rect" href="exchange.html">Exchange</a> at a given <a
shape="rect" href="endpoint.html">Endpoint</a> and the message is to be moved
into the dead letter queue, then Camel also decorates the Exchange with another
property that contains that <strong>last</strong> endpoint:</p><div class="code
panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
Modified: websites/production/camel/content/cache/main.pageCache
==============================================================================
Binary files - no diff available.
Modified: websites/production/camel/content/dead-letter-channel.html
==============================================================================
--- websites/production/camel/content/dead-letter-channel.html (original)
+++ websites/production/camel/content/dead-letter-channel.html Sun May 10
11:20:11 2015
@@ -90,7 +90,7 @@
<p class="title">Difference between Dead Letter Channel
and Default Error Handler</p>
<span class="aui-icon icon-success">Icon</span>
<div class="message-content">
- <p>The Default Error Handler does very little: it
ends the Exchange immediately and propagates the thrown Exception back to the
caller.</p><p>The Dead Letter Channel lets you control behaviors including
redelivery, whether to propagate the thrown Exception to the caller (the
<strong>handled</strong> option), and where the (failed) Exchange should now be
routed to.</p><p>When the DeadLetterChannel moves a message to the dead letter
endpoint, any new Exception thrown is by default handled by the dead letter
channel as well. This ensures that the DeadLetterChannel will always succeed.
From <strong>Camel 2.15</strong> 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.</p>
+ <p>The Default Error Handler does very little: it
ends the Exchange immediately and propagates the thrown Exception back to the
caller.</p><p>The Dead Letter Channel lets you control behaviors including
redelivery, whether to propagate the thrown Exception to the caller (the
<strong>handled</strong> option), and where the (failed) Exchange should now be
routed to.</p><p>The Dead Letter Channel is also by default configured to not
be verbose in the logs, so when a message is handled and moved to the dead
letter endpoint, then there is nothing logged. If you want some level of
logging you can use the various options on the redelivery policy / dead letter
channel to configure this. For example if you want the message history then set
logExhaustedMessageHistory=true (and logHandled=true for Camel 2.15.x or
older).</p><p>When the DeadLetterChannel moves a message to the dead letter
endpoint, any new Exception thrown is by default handled by the dead letter cha
nnel as well. This ensures that the DeadLetterChannel will always succeed.
From <strong>Camel 2.15</strong> 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.</p>
</div>
</div>
<h3 id="DeadLetterChannel-Redelivery">Redelivery</h3><p>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.</p><p>The <a shape="rect" class="external-link"
href="http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/processor/RedeliveryPolicy.html";>RedeliveryPolicy</a>
defines how the message is to be redelivered. You can customize things
like</p><ul><li>how many times a message is attempted to be redelivered before
it is considered a failure and sent to the dead letter channel</li><li>the
initial redelivery timeout</li><li>whether or not exponential backoff is used
(i.e. the time between retries increases using a backoff
multiplier)</li><li>whether to use collision
avoidance to add some randomness to the timings</li><li>delay pattern (see
below for details)</li><li><strong>Camel 2.11:</strong> whether to allow
redelivery during stopping/shutdown</li></ul><p>Once all attempts at
redelivering the message fails then the message is forwarded to the dead letter
queue.</p><h3
id="DeadLetterChannel-AboutmovingExchangetodeadletterqueueandusinghandled">About
moving Exchange to dead letter queue and using
handled</h3><p><strong>Handled</strong> on <a shape="rect"
href="dead-letter-channel.html">Dead Letter Channel</a></p><p>When all attempts
of redelivery have failed the <a shape="rect" href="exchange.html">Exchange</a>
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
<a shape="rect" href="dead-letter-channel.html">Dead Letter Channel</a> have
handled the <a shape="rect" href="exchange.html">Exchange</a>.</p><p>For
instance configuring the dead le
tter channel as:</p><p><strong>Using the <a shape="rect"
href="fluent-builders.html">Fluent Builders</a></strong></p><div class="code
panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
@@ -131,7 +131,7 @@
<p>We also support for per <a shape="rect"
href="exception-clause.html"><strong>onException</strong></a> to set a
<strong>onRedeliver</strong>. That means you can do special on redelivery for
different exceptions, as opposed to onRedelivery set on <a shape="rect"
href="dead-letter-channel.html">Dead Letter Channel</a> can be viewed as a
global scope.</p>
</div>
</div>
-<h3 id="DeadLetterChannel-Redeliverydefaultvalues">Redelivery default
values</h3><p>Redelivery is disabled by default.</p><p>The default redeliver
policy will use the following
values:</p><ul><li>maximumRedeliveries=0</li><li>redeliverDelay=1000L (1
second)</li><li>maximumRedeliveryDelay = 60 * 1000L (60 seconds)</li><li>And
the exponential backoff and collision avoidance is turned off.</li><li>The
retriesExhaustedLogLevel are set to LoggingLevel.ERROR</li><li>The
retryAttemptedLogLevel are set to LoggingLevel.DEBUG</li><li>Stack traces is
logged for exhausted messages from Camel 2.2 onwards.</li><li>Handled
exceptions is not logged from Camel 2.3 onwards</li></ul><p>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.</p><p>The
maximum redeliveries is the number of <strong>re</strong> delivery attempts. By
default Camel will try to process the exchange 1 + 5 times. 1 time for the n
ormal attempt and then 5 attempts as redeliveries.<br clear="none"> Setting
the maximumRedeliveries to a negative value such as -1 will then always
redelivery (unlimited).<br clear="none"> Setting the maximumRedeliveries to 0
will disable any re delivery attempt.</p><p>Camel will log delivery failures at
the DEBUG logging level by default. You can change this by specifying
retriesExhaustedLogLevel and/or retryAttemptedLogLevel. See <a shape="rect"
class="external-link"
href="http://svn.apache.org/repos/asf/camel/trunk/camel-core/src/test/java/org/apache/camel/builder/ExceptionBuilderWithRetryLoggingLevelSetTest.java";>ExceptionBuilderWithRetryLoggingLevelSetTest</a>
for an example.</p><p>You can turn logging of stack traces on/off. If turned
off Camel will still log the redelivery attempt. Its just much less
verbose.</p><h4 id="DeadLetterChannel-RedeliverDelayPattern">Redeliver Delay
Pattern</h4><p>Delay pattern is used as a single option to set a range pattern
for delays. If used th
en the following options does not apply: (delay, backOffMultiplier,
useExponentialBackOff, useCollisionAvoidance,
maximumRedeliveryDelay).</p><p>The idea is to set groups of ranges using the
following syntax: <code>limit:delay;limit 2:delay 2;limit 3:delay 3;...;limit
N:delay N</code></p><p>Each group has two values separated with colon</p><ul
class="alternate"><li>limit = upper limit</li><li>delay = delay in millis<br
clear="none"> And the groups is again separated with semi colon.<br
clear="none"> The rule of thumb is that the next groups should have a higher
limit than the previous group.</li></ul><p>Lets clarify this with an
example:<br clear="none">
<code>delayPattern=5:1000;10:5000;20:20000</code></p><p>That gives us 3
groups:</p><ul
class="alternate"><li>5:1000</li><li>10:5000</li><li>20:20000</li></ul><p>Resulting
in these delays for redelivery attempt:</p><ul
class="alternate"><li>Redelivery attempt number 1..4 = 0 millis (as the first
group start with 5)</li><li>Redelivery
attempt number 5..9 = 1000 millis (the first group)</li><li>Redelivery
attempt number 10..19 = 5000 millis (the second group)</li><li>Redelivery
attempt number 20.. = 20000 millis (the last group)</li></ul><p>Note: The first
redelivery attempt is 1, so the first group should start with 1 or
higher.</p><p>You can start a group with limit 1 to eg have a starting delay:
<code>delayPattern=1:1000;5:5000</code></p><ul class="alternate"><li>Redelivery
attempt number 1..4 = 1000 millis (the first group)</li><li>Redelivery attempt
number 5.. = 5000 millis (the last group)</li></ul><p>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 <code>delayPattern=1:5000;3:1000</code> we
start with 5 sec delay and then later reduce that to 1 second.</p><h3
id="DeadLetterChannel-Redeliveryheader">Redelivery header</h3><p>When a message
is redelivered the <a shape="rect" class="external-link"
href="http://camel.apache.or
g/maven/camel-core/apidocs/org/apache/camel/processor/DeadLetterChannel.html">DeadLetterChannel</a>
will append a customizable header to the message to indicate how many times
its been redelivered. <br clear="none"> Before Camel 2.6: The header is
<strong>CamelRedeliveryCounter</strong>, which is also defined on the
<code>Exchange.REDELIVERY_COUNTER</code>.<br clear="none"> Starting with 2.6:
The header <strong>CamelRedeliveryMaxCounter</strong>, which is also defined on
the <code>Exchange.REDELIVERY_MAX_COUNTER</code>, contains the maximum
redelivery setting. This header is absent if you use <code>retryWhile</code> or
have unlimited maximum redelivery configured.</p><p>And a boolean flag whether
it is being redelivered or not (first attempt)<br clear="none"> The header
<strong>CamelRedelivered</strong> contains a boolean if the message is
redelivered or not, which is also defined on the
<code>Exchange.REDELIVERED</code>.</p><p>Dynamically calculated delay from the
exchange<br clear
="none"> In Camel 2.9 and 2.8.2: The header is
<strong>CamelRedeliveryDelay</strong>, which is also defined on the
<code>Exchange.REDELIVERY_DELAY</code>.<br clear="none"> Is this header is
absent, normal redelivery rules apply.</p><h4
id="DeadLetterChannel-Whichendpointfailed">Which endpoint
failed</h4><p><strong>Available as of Camel 2.1</strong></p><p>When Camel
routes messages it will decorate the <a shape="rect"
href="exchange.html">Exchange</a> with a property that contains the
<strong>last</strong> endpoint Camel send the <a shape="rect"
href="exchange.html">Exchange</a> to:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<h3 id="DeadLetterChannel-Redeliverydefaultvalues">Redelivery default
values</h3><p>Redelivery is disabled by default.</p><p>The default redeliver
policy will use the following
values:</p><ul><li>maximumRedeliveries=0</li><li>redeliverDelay=1000L (1
second)</li><li>maximumRedeliveryDelay = 60 * 1000L (60 seconds)</li><li>And
the exponential backoff and collision avoidance is turned off.</li><li>The
retriesExhaustedLogLevel are set to LoggingLevel.ERROR</li><li>The
retryAttemptedLogLevel are set to LoggingLevel.DEBUG</li><li>Stack traces is
logged for exhausted messages from Camel 2.2 onwards.</li><li>Handled
exceptions is not logged from Camel 2.3
onwards</li><li>logExhaustedMessageHistory is true for default error handler,
and false for dead letter channel.</li></ul><p>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.</p><p>The maximum redeliveries
is the number of <strong>re</s
trong> 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.<br clear="none"> Setting the maximumRedeliveries to a negative
value such as -1 will then always redelivery (unlimited).<br clear="none">
Setting the maximumRedeliveries to 0 will disable any re delivery
attempt.</p><p>Camel will log delivery failures at the DEBUG logging level by
default. You can change this by specifying retriesExhaustedLogLevel and/or
retryAttemptedLogLevel. See <a shape="rect" class="external-link"
href="http://svn.apache.org/repos/asf/camel/trunk/camel-core/src/test/java/org/apache/camel/builder/ExceptionBuilderWithRetryLoggingLevelSetTest.java";>ExceptionBuilderWithRetryLoggingLevelSetTest</a>
for an example.</p><p>You can turn logging of stack traces on/off. If turned
off Camel will still log the redelivery attempt. Its just much less
verbose.</p><h4 id="DeadLetterChannel-RedeliverDelayPattern">Redeliver De
lay Pattern</h4><p>Delay pattern is used as a single option to set a range
pattern for delays. If used then the following options does not apply: (delay,
backOffMultiplier, useExponentialBackOff, useCollisionAvoidance,
maximumRedeliveryDelay).</p><p>The idea is to set groups of ranges using the
following syntax: <code>limit:delay;limit 2:delay 2;limit 3:delay 3;...;limit
N:delay N</code></p><p>Each group has two values separated with colon</p><ul
class="alternate"><li>limit = upper limit</li><li>delay = delay in millis<br
clear="none"> And the groups is again separated with semi colon.<br
clear="none"> The rule of thumb is that the next groups should have a higher
limit than the previous group.</li></ul><p>Lets clarify this with an
example:<br clear="none">
<code>delayPattern=5:1000;10:5000;20:20000</code></p><p>That gives us 3
groups:</p><ul
class="alternate"><li>5:1000</li><li>10:5000</li><li>20:20000</li></ul><p>Resulting
in these delays for redelivery attempt:</p><ul class="alte
rnate"><li>Redelivery attempt number 1..4 = 0 millis (as the first group start
with 5)</li><li>Redelivery attempt number 5..9 = 1000 millis (the first
group)</li><li>Redelivery attempt number 10..19 = 5000 millis (the second
group)</li><li>Redelivery attempt number 20.. = 20000 millis (the last
group)</li></ul><p>Note: The first redelivery attempt is 1, so the first group
should start with 1 or higher.</p><p>You can start a group with limit 1 to eg
have a starting delay: <code>delayPattern=1:1000;5:5000</code></p><ul
class="alternate"><li>Redelivery attempt number 1..4 = 1000 millis (the first
group)</li><li>Redelivery attempt number 5.. = 5000 millis (the last
group)</li></ul><p>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
<code>delayPattern=1:5000;3:1000</code> we start with 5 sec delay and then
later reduce that to 1 second.</p><h3
id="DeadLetterChannel-Redeliveryheader">Redelivery header</h
3><p>When a message is redelivered the <a shape="rect" class="external-link"
href="http://camel.apache.org/maven/camel-core/apidocs/org/apache/camel/processor/DeadLetterChannel.html";>DeadLetterChannel</a>
will append a customizable header to the message to indicate how many times
its been redelivered. <br clear="none"> Before Camel 2.6: The header is
<strong>CamelRedeliveryCounter</strong>, which is also defined on the
<code>Exchange.REDELIVERY_COUNTER</code>.<br clear="none"> Starting with 2.6:
The header <strong>CamelRedeliveryMaxCounter</strong>, which is also defined on
the <code>Exchange.REDELIVERY_MAX_COUNTER</code>, contains the maximum
redelivery setting. This header is absent if you use <code>retryWhile</code> or
have unlimited maximum redelivery configured.</p><p>And a boolean flag whether
it is being redelivered or not (first attempt)<br clear="none"> The header
<strong>CamelRedelivered</strong> contains a boolean if the message is
redelivered or not, which is also define
d on the <code>Exchange.REDELIVERED</code>.</p><p>Dynamically calculated delay
from the exchange<br clear="none"> In Camel 2.9 and 2.8.2: The header is
<strong>CamelRedeliveryDelay</strong>, which is also defined on the
<code>Exchange.REDELIVERY_DELAY</code>.<br clear="none"> Is this header is
absent, normal redelivery rules apply.</p><h4
id="DeadLetterChannel-Whichendpointfailed">Which endpoint
failed</h4><p><strong>Available as of Camel 2.1</strong></p><p>When Camel
routes messages it will decorate the <a shape="rect"
href="exchange.html">Exchange</a> with a property that contains the
<strong>last</strong> endpoint Camel send the <a shape="rect"
href="exchange.html">Exchange</a> to:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[String lastEndpointUri =
exchange.getProperty(Exchange.TO_ENDPOINT, String.class);
]]></script>
</div></div><p>The <code>Exchange.TO_ENDPOINT</code> have the constant value
<code>CamelToEndpoint</code>.</p><p>This information is updated when Camel
sends a message to any endpoint. So if it exists its the <strong>last</strong>
endpoint which Camel send the Exchange to.</p><p>When for example processing
the <a shape="rect" href="exchange.html">Exchange</a> at a given <a
shape="rect" href="endpoint.html">Endpoint</a> and the message is to be moved
into the dead letter queue, then Camel also decorates the Exchange with another
property that contains that <strong>last</strong> endpoint:</p><div class="code
panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
