svn commit: r1021778 - in /websites/production/camel/content: cache/main.pageCache error-handling-in-camel.html

[bu...@apache.org]

Author: buildbot
Date: Wed Dec  6 02:33:51 2017
New Revision: 1021778

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 Wed Dec  6 02:33:51 2017
@@ -84,7 +84,7 @@
 	<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="confluence-information-macro confluence-information-macro-tip"><p class="title">Using try ... catch ... finally</p><span class="aui-icon aui-icon-small aui-iconfont-approve confluence-information-macro-icon"></span><div class="confluence-information-macro-body"><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><p>any uncaught exception is thrown during routing and processing of messages within Camel</p><div class="confluence-information-macro confluence-information-macro-tip"><span class="aui-icon aui-icon-small aui-iconfont-approve confluence-information-macro-icon"></span><div class="confluence-information-macro-body"><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/5997/6f42626d00e36f53fe51440403446ca61552e2a2.1/_/images/icons/emoticons/star_yellow.png" data-emoticon-name="yellow-star" alt="(star)"></li></ul><div class="confluence-information-macro confluence-information-macro-warning"><p class="title">Dead Letter Queue (*)</p><span class="aui-icon aui-icon-small aui-iconfont-error confluence-information-macro-icon"></span><div class="confluence-information-macro-body"><p>A dead letter queue is like a black hole, it will consume the <a shape="rect" h
 ref="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 g
 lobal <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></th></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>XML DSL</p></td><td colspan="1" rowspan="1" class="confluenceTd"><p>Camel
 Context</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="confluence-information-macro confluence-information-macro-tip"><span class="aui-icon aui-icon-small aui-iconfont-approve confluence-information-macro-icon"></span><div class="confluence-information-macro-body"><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">
+<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="confluence-information-macro confluence-information-macro-tip"><p class="title">Using try ... catch ... finally</p><span class="aui-icon aui-icon-small aui-iconfont-approve confluence-information-macro-icon"></span><div class="confluence-information-macro-body"><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><p>any uncaught exception is thrown during routing and processing of messages within Camel</p><div class="confluence-information-macro confluence-information-macro-tip"><span class="aui-icon aui-icon-small aui-iconfont-approve confluence-information-macro-icon"></span><div class="confluence-information-macro-body"><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/5997/6f42626d00e36f53fe51440403446ca61552e2a2.1/_/images/icons/emoticons/star_yellow.png" data-emoticon-name="yellow-star" alt="(star)"></li></ul><div class="confluence-information-macro confluence-information-macro-warning"><p class="title">Dead Letter Queue (*)</p><span class="aui-icon aui-icon-small aui-iconfont-error confluence-information-macro-icon"></span><div class="confluence-information-macro-body"><p>A dead letter queue is like a black hole, it will consume the <a shape="rect" h
 ref="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 will still want a response after the failure.</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 Cam
 el 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></th></tr><tr><td colspan="1" rowspan="1" class="confluenceTd"><p>XML DSL</p></td><td colspan="1" rowspan="1" class="conf
 luenceTd"><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="confluence-information-macro confluence-information-macro-tip"><span class="aui-icon aui-icon-small aui-iconfont-approve confluence-information-macro-icon"></span><div class="confluence-information-mac
 ro-body"><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="brush: java; gutter: false; theme: Default" type="syntaxhighlighter"><![CDATA[errorHandler(deadLetterChannel(&quot;jms:queue:dead&quot;));
 
 from(&quot;seda:newOrder&quot;)