Author: buildbot
Date: Thu Mar 13 17:19:36 2014
New Revision: 901461
Log:
Production update by buildbot for camel
Modified:
websites/production/camel/content/cache/main.pageCache
websites/production/camel/content/error-handling-in-camel.html
Modified: websites/production/camel/content/cache/main.pageCache
==============================================================================
Binary files - no diff available.
Modified: websites/production/camel/content/error-handling-in-camel.html
==============================================================================
--- websites/production/camel/content/error-handling-in-camel.html (original)
+++ websites/production/camel/content/error-handling-in-camel.html Thu Mar 13
17:19:36 2014
@@ -84,131 +84,47 @@
<tbody>
<tr>
<td valign="top" width="100%">
-<div class="wiki-content maincontent"><h2
id="ErrorhandlinginCamel-ErrorhandlinginCamel">Error handling in Camel</h2>
-
-<p>Error handling in Camel can roughly be separated into two distinct
types:</p>
-<ul class="alternate"><li>non transactional</li><li>transactional</li></ul>
-
-
-<p>Where non transactional is the most common type that is enabled
out-of-the-box and handled by Camel itself. The transaction type is handled by
a backing system such as a J2EE application server.</p>
-
- <div class="aui-message success shadowed information-macro">
+<div class="wiki-content maincontent"><h2
id="ErrorhandlinginCamel-ErrorhandlinginCamel">Error handling in
Camel</h2><p>Error handling in Camel can roughly be separated into two distinct
types:</p><ul class="alternate"><li>non
transactional</li><li>transactional</li></ul><p>Where non transactional is the
most common type that is enabled out-of-the-box and handled by Camel itself.
The transaction type is handled by a backing system such as a J2EE application
server.</p> <div class="aui-message success shadowed information-macro">
<p class="title">Using try ... catch ... finally</p>
<span class="aui-icon icon-success">Icon</span>
<div class="message-content">
-
-<p>Related to error handling is the <a shape="rect"
href="try-catch-finally.html">Try Catch Finally</a> feature in Camel. </p>
+ <p>Related to error handling is the <a
shape="rect" href="try-catch-finally.html">Try Catch Finally</a> feature in
Camel.</p>
</div>
</div>
-
-
-<h3 id="ErrorhandlinginCamel-Whendoesanerrorhappen">When does an error
happen</h3>
-<p>An error happens when</p>
-<ul class="alternate"><li>any uncaught exception is thrown during routing and
processing of messages within Camel
- <div class="aui-message success shadowed information-macro">
+<h3 id="ErrorhandlinginCamel-Whendoesanerrorhappen">When does an error
happen</h3><p>An error happens when</p><ul class="alternate"><li><p>any
uncaught exception is thrown during routing and processing of messages within
Camel</p> <div class="aui-message success shadowed information-macro">
<span class="aui-icon icon-success">Icon</span>
<div class="message-content">
-
-<p>So think of this as a big exception interceptor that catches all exceptions
and handles what to do.</p>
+ <p>So think of this as a big exception interceptor
that catches all exceptions and handles what to do.</p>
</div>
</div>
-</li></ul>
-
-
-<h3 id="ErrorhandlinginCamel-Nontransactional">Non transactional</h3>
-<p>By default Camel uses the non transaction type and orchestrates the error
handling during processing and routing.</p>
-
-<p>As there isn't a single error handling configuration that suites all uses
cases, you should consider altering the default configurations to better suit
you needs.</p>
-
-<h4 id="ErrorhandlinginCamel-Camel1.xdefaulterrorhandler">Camel 1.x default
error handler</h4>
-<p>In Camel 1.x a global <a shape="rect" href="dead-letter-channel.html">Dead
Letter Channel</a> is setup as the <a shape="rect"
href="error-handler.html">Error Handler</a> by default. It's configured as:</p>
-<ul class="alternate"><li>redeliver up to 6 times</li><li>pause 1 second
between each redelivery attempt</li><li>if all redelivery attempts failed then
move exchange into the dead letter queue</li><li>the default dead letter queue
is a logger that logs the exchange at ERROR level <img class="emoticon
emoticon-yellow-star"
src="https://cwiki.apache.org/confluence/s/en_GB-1988229788/4109/76e0dbb30bc8580e459c201f3535d84f9283a9ac.1/_/images/icons/emoticons/star_yellow.png";
data-emoticon-name="yellow-star" alt="(star)"></li></ul>
-
-
- <div class="aui-message problem shadowed information-macro">
+</li></ul><h3 id="ErrorhandlinginCamel-Nontransactional">Non
transactional</h3><p>By default Camel uses the non transaction type and
orchestrates the error handling during processing and routing.</p><p>As there
isn't a single error handling configuration that suites all uses cases, you
should consider altering the default configurations to better suit you
needs.</p><h4 id="ErrorhandlinginCamel-Camel1.xdefaulterrorhandler">Camel 1.x
default error handler</h4><p>In Camel 1.x a global <a shape="rect"
href="dead-letter-channel.html">Dead Letter Channel</a> is setup as the <a
shape="rect" href="error-handler.html">Error Handler</a> by default. It's
configured as:</p><ul class="alternate"><li>redeliver up to 6
times</li><li>pause 1 second between each redelivery attempt</li><li>if all
redelivery attempts failed then move exchange into the dead letter
queue</li><li>the default dead letter queue is a logger that logs the exchange
at ERROR level <img class="emoticon emoticon-yellow-star" src
="https://cwiki.apache.org/confluence/s/en_GB-1988229788/4109/76e0dbb30bc8580e459c201f3535d84f9283a9ac.1/_/images/icons/emoticons/star_yellow.png";
data-emoticon-name="yellow-star" alt="(star)"></li></ul> <div
class="aui-message problem shadowed information-macro">
<p class="title">Dead Letter Queue (*)</p>
<span class="aui-icon icon-problem">Icon</span>
<div class="message-content">
-
-<p>A dead letter queue is like a black hole, it will consume the <a
shape="rect" href="exchange.html">Exchange</a> and the <a shape="rect"
href="exchange.html">Exchange</a> routing is ended with no indication that it
failed.<br clear="none">
-This works great in the <a shape="rect" href="jms.html">JMS</a> Messaging
world where we don't want a bad message to cause endless retries and causing
the system to exhaust. The message is said to be poison and thus we want to
move it to a dead letter queue so the system can continue to operate and work
with the next message.</p>
-
-<p>This default does not go well with other transports using in a
request/reply messaging style. If the <a shape="rect"
href="exchange.html">Exchange</a> failed then the original caller want to be
alter it failed.</p>
-
-<p>So the bottom line is that you <strong>must</strong> configure and setup
the error handling strategies that suits your business needs.</p>
+ <p>A dead letter queue is like a black hole, it
will consume the <a shape="rect" href="exchange.html">Exchange</a> and the <a
shape="rect" href="exchange.html">Exchange</a> routing is ended with no
indication that it failed.<br clear="none"> This works great in the <a
shape="rect" href="jms.html">JMS</a> Messaging world where we don't want a bad
message to cause endless retries and causing the system to exhaust. The message
is said to be poison and thus we want to move it to a dead letter queue so the
system can continue to operate and work with the next message.</p><p>This
default does not go well with other transports using in a request/reply
messaging style. If the <a shape="rect" href="exchange.html">Exchange</a>
failed then the original caller want to be alter it failed.</p><p>So the bottom
line is that you <strong>must</strong> configure and setup the error handling
strategies that suits your business needs.</p>
</div>
</div>
-
-
-<h4 id="ErrorhandlinginCamel-Camel2.0onwardsdefaulterrorhandler">Camel 2.0
onwards default error handler</h4>
-<p>In Camel 2.0 onwards a global <a shape="rect"
href="defaulterrorhandler.html">DefaultErrorHandler</a> is setup as the <a
shape="rect" href="error-handler.html">Error Handler</a> by default. It's
configured as:</p>
-<ul class="alternate"><li>no redeliveries</li><li>no deal letter
queue</li><li>if the exchange failed an exception is thrown and propagated back
to the original caller wrapped in a
<code>RuntimeCamelException</code>.</li></ul>
-
-
-<h3 id="ErrorhandlinginCamel-Scopes">Scopes</h3>
-<p>Camel supports 2 scopes that is determined by the DSL in use:</p>
-<div class="table-wrap"><table class="confluenceTable"><tbody><tr><th
colspan="1" rowspan="1" class="confluenceTh"><p> DSL </p></th><th colspan="1"
rowspan="1" class="confluenceTh"><p> Scope 1 </p></th><th colspan="1"
rowspan="1" class="confluenceTh"><p> Scope 2 </p></th><th colspan="1"
rowspan="1" class="confluenceTh"><p> Note </p></th></tr><tr><td colspan="1"
rowspan="1" class="confluenceTd"><p> XML DSL </p></td><td colspan="1"
rowspan="1" class="confluenceTd"><p> CamelContext </p></td><td colspan="1"
rowspan="1" class="confluenceTd"><p> route </p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p> Scope 2 takes precedence over scope 1
</p></td></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>
Java/Scala DSL </p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>
RouteBuilder </p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>
route </p></td><td colspan="1" rowspan="1" class="confluenceTd"><p> Scope 2
takes precedence over scope 1 </p></td></tr></
tbody></table></div>
-
-
-<p>When using XML DSL then scope 1 applies for all routes. Where as when using
Java DSL then route 1 only applies for the given RouteBuilder instance. So if
you have multiple RouteBuilder's then each route builder has its own scope 1.
</p>
-
- <div class="aui-message success shadowed information-macro">
+<h4 id="ErrorhandlinginCamel-Camel2.0onwardsdefaulterrorhandler">Camel 2.0
onwards default error handler</h4><p>In Camel 2.0 onwards a global <a
shape="rect" href="defaulterrorhandler.html">DefaultErrorHandler</a> is set up
as the <a shape="rect" href="error-handler.html">Error Handler</a> by default.
It's configured as:</p><ul class="alternate"><li>no redeliveries</li><li>no
dead letter queue</li><li>if the exchange failed an exception is thrown and
propagated back to the original caller wrapped in a
<code>RuntimeCamelException</code>.</li></ul><h3
id="ErrorhandlinginCamel-Scopes">Scopes</h3><p>Camel supports 2 scopes that is
determined by the DSL in use:</p><div class="table-wrap"><table
class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1"
class="confluenceTh"><p>DSL</p></th><th colspan="1" rowspan="1"
class="confluenceTh"><p>Scope 1</p></th><th colspan="1" rowspan="1"
class="confluenceTh"><p>Scope 2</p></th><th colspan="1" rowspan="1"
class="confluenceTh"><p>Note</p></t
h></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>XML
DSL</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>CamelContext</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>route</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>Scope 2 takes precedence over scope
1</p></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p>Java/Scala DSL</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>RouteBuilder</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>route</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>Scope 2 takes precedence over scope
1</p></td></tr></tbody></table></div><p>When using XML DSL then scope 1 applies
for all routes. Where as when using Java DSL then route 1 only applies for the
given RouteBuilder instance. So if you have multiple RouteBuilder's then each
route builder has its own scope 1.</p> <div class="aui-message success
shadowed information-macro">
<span class="aui-icon icon-success">Icon</span>
<div class="message-content">
-
-<p>If you want to share scope among RouteBuilder's you can use class
inheritance and create a base class, and then extend this class for your
RouteBuilder's and invoke the super.configure() method.</p>
+ <p>If you want to share scope among RouteBuilder's
you can use class inheritance and create a base class, and then extend this
class for your RouteBuilder's and invoke the super.configure() method.</p>
</div>
</div>
-
-
-<p>Mind that there was a bug in Camel that affected the scopes when using
multiple RouteBuilder classes. See more details at <a shape="rect"
class="external-link"
href="https://issues.apache.org/jira/browse/CAMEL-5456";>CAMEL-5456</a>.</p>
-
-<h3 id="ErrorhandlinginCamel-Howdoestheerrorhandlerwork">How does the <a
shape="rect" href="dead-letter-channel.html">Dead Letter Channel</a> error
handler work</h3>
-<p>When Camel is started it will inspect the routes and weave in the error
handling into the routing. With up to 3 supported scopes, the error handling
can be quite complex. And on top of that you have inherited error handling and
you can even configure <a shape="rect" href="exception-clause.html">Exception
Clause</a>s to handle specific exception types differently. So yes it's
advanced but very powerful when you get the grip of it.</p>
-
-<p>To keep things simple we first look at the basic concept how Camel
orchestrates the redelivery attempt. At any given node in the route graph Camel
intercepts the current Exchange being routed and wraps it with the <a
shape="rect" href="error-handler.html">Error Handler</a>. This ensures that the
<a shape="rect" href="error-handler.html">Error Handler</a> can kick in, just
as the AOP around concept. If the exchange can be routed without any problems
then it's forwarded to the next node in the route graph, <strong>But</strong>
if there was an exception thrown, then the <a shape="rect"
href="error-handler.html">Error Handler</a> kicks in and decides what to do.
</p>
-
-<p>An example illustrating this:</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[
-errorHandler(deadLetterChannel("jms:queue:dead"));
+<p>Mind that there was a bug in Camel that affected the scopes when using
multiple RouteBuilder classes. See more details at <a shape="rect"
class="external-link"
href="https://issues.apache.org/jira/browse/CAMEL-5456";>CAMEL-5456</a>.</p><h3
id="ErrorhandlinginCamel-Howdoestheerrorhandlerwork">How does the <a
shape="rect" href="dead-letter-channel.html">Dead Letter Channel</a> error
handler work</h3><p>When Camel is started it will inspect the routes and weave
in the error handling into the routing. With up to 3 supported scopes, the
error handling can be quite complex. And on top of that you have inherited
error handling and you can even configure <a shape="rect"
href="exception-clause.html">Exception Clause</a>s to handle specific exception
types differently. So yes it's advanced but very powerful when you get the grip
of it.</p><p>To keep things simple we first look at the basic concept how Camel
orchestrates the redelivery attempt. At any given node in the route graph Camel
inte
rcepts the current Exchange being routed and wraps it with the <a shape="rect"
href="error-handler.html">Error Handler</a>. This ensures that the <a
shape="rect" href="error-handler.html">Error Handler</a> can kick in, just as
the AOP around concept. If the exchange can be routed without any problems then
it's forwarded to the next node in the route graph, <strong>But</strong> if
there was an exception thrown, then the <a shape="rect"
href="error-handler.html">Error Handler</a> kicks in and decides what to
do.</p><p>An example illustrating this:</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[errorHandler(deadLetterChannel("jms:queue:dead"));
from("seda:newOrder")
.to("bean:validateOrder")
.to("bean:storeOrder")
.to("bean:confirmOrder");
]]></script>
-</div></div>
-
-<p>In this route we have 3 nodes (the dots) where the <a shape="rect"
href="error-handler.html">Error Handler</a> is watching us (The AOP around
stuff). So when an order arrives on the seda queue we consume it and send it to
the validateOrder bean. In case the validation bean processed ok, we move on to
the next node. In case the storeOrder bean failed and throws an exception it's
caught by the <a shape="rect" href="dead-letter-channel.html">Dead Letter
Channel</a> that decides what to do next. Either it does a:</p>
-<ul class="alternate"><li>redeliver</li><li>or move it to dead letter
queue</li></ul>
-
-
-<p>It will continue to do redeliveries based on the policy configured. By
default <a shape="rect" href="dead-letter-channel.html">Dead Letter Channel</a>
will attempt at most 6 redeliveries with 1 second delay. So if the storeOrder
bean did succeed at the 3rd attempt the routing will continue to the next node
the confirmOrder bean. In case all redeliveries failed the Exchange is regarded
as failed and is moved to the dead letter queue and the processing of this
exchange stops. By default the dead letter queue is just a ERROR logger.</p>
-
- <div class="aui-message hint shadowed information-macro">
+</div></div><p>In this route we have 3 nodes (the dots) where the <a
shape="rect" href="error-handler.html">Error Handler</a> is watching us (The
AOP around stuff). So when an order arrives on the seda queue we consume it and
send it to the validateOrder bean. In case the validation bean processed ok, we
move on to the next node. In case the storeOrder bean failed and throws an
exception it's caught by the <a shape="rect"
href="dead-letter-channel.html">Dead Letter Channel</a> that decides what to do
next. Either it does a:</p><ul class="alternate"><li>redeliver</li><li>or move
it to dead letter queue</li></ul><p>It will continue to do redeliveries based
on the policy configured. By default <a shape="rect"
href="dead-letter-channel.html">Dead Letter Channel</a> will attempt at most 6
redeliveries with 1 second delay. So if the storeOrder bean did succeed at the
3rd attempt the routing will continue to the next node the confirmOrder bean.
In case all redeliveries failed the Exchange
is regarded as failed and is moved to the dead letter queue and the processing
of this exchange stops. By default the dead letter queue is just a ERROR
logger.</p> <div class="aui-message hint shadowed information-macro">
<span class="aui-icon icon-hint">Icon</span>
<div class="message-content">
-
-<p>This applies to all kind of <a shape="rect"
href="components.html">Components</a> in Camel. The sample above only uses <a
shape="rect" href="bean.html">Bean</a> but it's the same for <a shape="rect"
href="file2.html">File</a>, <a shape="rect" href="mail.html">Mail</a>, <a
shape="rect" href="velocity.html">Velocity</a> or whatever component you
use.</p>
+ <p>This applies to all kind of <a shape="rect"
href="components.html">Components</a> in Camel. The sample above only uses <a
shape="rect" href="bean.html">Bean</a> but it's the same for <a shape="rect"
href="file2.html">File</a>, <a shape="rect" href="mail.html">Mail</a>, <a
shape="rect" href="velocity.html">Velocity</a> or whatever component you
use.</p>
</div>
</div>
-
-
-<h3 id="ErrorhandlinginCamel-Transactional">Transactional</h3>
-<p>Camel leverages Spring transactions. Usually you can only use this with a
limited number of transport types such as JMS or JDBC based, that yet again
requires a transaction manager such as a Spring transaction, a J2EE server or a
Message Broker.</p>
-
-<h4 id="ErrorhandlinginCamel-Howdoesitwork">How does it work</h4>
-<p><strong>Camel 1.x</strong><br clear="none">
-Camel does the same weaving as for the non-transactional type. The difference
is that for transactional exchanges the <a shape="rect"
href="error-handler.html">Error Handler</a> does <strong>not</strong> kick in.
You can say the AOP around does not apply. Camel relies solely on the backing
system to orchestrate the error handling. And as such the when the backing
system does redeliver it will start all over again. For instance if the
exchange was started by a JMS consumer then it's started again as the JMS
message is rolled back on the JMS queue and Camel will re consume the JMS
message again.</p>
-
-<p><strong>Camel 2.0</strong><br clear="none">
-In Camel 2.0 we have empowered the <a shape="rect"
href="transactionerrorhandler.html">TransactionErrorHandler</a> to build on top
of the same base that <a shape="rect"
href="defaulterrorhandler.html">DefaultErrorHandler</a> does. This allows you
to use Camel redelivery with transactional routes as well. The Spring
transaction manager is still in charge and have the last say. But you can use
Camel to do some local redelivery, for instance to upload a file to a FTP
server, in which Camel can do local redelivery. So this gives you the power
from both worlds. In case Camel cannot redeliver the exchange will be failed
and rolled back. By default the <a shape="rect"
href="transactionerrorhandler.html">TransactionErrorHandler</a> does
<strong>not</strong> attempt any local redeliveries. You have to configure it
to do so, for instance to set a maximum redelivers to a number > 0.</p>
-
-<p>See <a shape="rect" href="transactional-client.html">Transactional
Client</a> for more.</p>
-
-<h2 id="ErrorhandlinginCamel-Seealso">See also</h2>
-<ul class="alternate"><li><a shape="rect" href="error-handler.html">Error
Handler</a></li><li><a shape="rect" href="dead-letter-channel.html">Dead Letter
Channel</a></li><li><a shape="rect" href="exception-clause.html">Exception
Clause</a></li><li><a shape="rect"
href="transactional-client.html">Transactional Client</a></li><li><a
shape="rect"
href="transactionerrorhandler.html">TransactionErrorHandler</a></li><li><a
shape="rect" href="defaulterrorhandler.html">DefaultErrorHandler</a></li><li><a
shape="rect" href="try-catch-finally.html">Try Catch Finally</a></li></ul></div>
+<h3 id="ErrorhandlinginCamel-Transactional">Transactional</h3><p>Camel
leverages Spring transactions. Usually you can only use this with a limited
number of transport types such as JMS or JDBC based, that yet again requires a
transaction manager such as a Spring transaction, a J2EE server or a Message
Broker.</p><h4 id="ErrorhandlinginCamel-Howdoesitwork">How does it
work</h4><p><strong>Camel 1.x</strong><br clear="none"> Camel does the same
weaving as for the non-transactional type. The difference is that for
transactional exchanges the <a shape="rect" href="error-handler.html">Error
Handler</a> does <strong>not</strong> kick in. You can say the AOP around does
not apply. Camel relies solely on the backing system to orchestrate the error
handling. And as such the when the backing system does redeliver it will start
all over again. For instance if the exchange was started by a JMS consumer then
it's started again as the JMS message is rolled back on the JMS queue and Camel
will re c
onsume the JMS message again.</p><p><strong>Camel 2.0</strong><br
clear="none"> In Camel 2.0 we have empowered the <a shape="rect"
href="transactionerrorhandler.html">TransactionErrorHandler</a> to build on top
of the same base that <a shape="rect"
href="defaulterrorhandler.html">DefaultErrorHandler</a> does. This allows you
to use Camel redelivery with transactional routes as well. The Spring
transaction manager is still in charge and have the last say. But you can use
Camel to do some local redelivery, for instance to upload a file to a FTP
server, in which Camel can do local redelivery. So this gives you the power
from both worlds. In case Camel cannot redeliver the exchange will be failed
and rolled back. By default the <a shape="rect"
href="transactionerrorhandler.html">TransactionErrorHandler</a> does
<strong>not</strong> attempt any local redeliveries. You have to configure it
to do so, for instance to set a maximum redelivers to a number >
0.</p><p>See <a shape="rect" hre
f="transactional-client.html">Transactional Client</a> for more.</p><h2
id="ErrorhandlinginCamel-Seealso">See also</h2><ul class="alternate"><li><a
shape="rect" href="error-handler.html">Error Handler</a></li><li><a
shape="rect" href="dead-letter-channel.html">Dead Letter Channel</a></li><li><a
shape="rect" href="exception-clause.html">Exception Clause</a></li><li><a
shape="rect" href="transactional-client.html">Transactional
Client</a></li><li><a shape="rect"
href="transactionerrorhandler.html">TransactionErrorHandler</a></li><li><a
shape="rect" href="defaulterrorhandler.html">DefaultErrorHandler</a></li><li><a
shape="rect" href="try-catch-finally.html">Try Catch Finally</a></li></ul></div>
</td>
<td valign="top">
<div class="navigation">
![https://cwiki.apache.org/confluence/s/en_GB-1988229788/4109/76e0dbb30bc8580e459c201f3535d84f9283a9ac.1/_/images/icons/emoticons/star_yellow.png"](https://cwiki.apache.org/confluence/s/en_GB-1988229788/4109/76e0dbb30bc8580e459c201f3535d84f9283a9ac.1/_/images/icons/emoticons/star_yellow.png"){kind=link}