You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@camel.apache.org by bu...@apache.org on 2014/03/13 18:19:36 UTC
svn commit: r901461 - in /websites/production/camel/content:
cache/main.pageCache error-handling-in-camel.html
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">