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

[bu...@apache.org]

Author: buildbot
Date: Wed Oct 28 18:19:03 2015
New Revision: 970522

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 Oct 28 18:19:03 2015
@@ -92,7 +92,7 @@ from("seda:newOrder")
    .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="confluence-information-macro confluence-information-macro-information"><span class="aui-icon aui-icon-small aui-iconfont-info confluence-information-macro-icon"></span><div class="confluence-information-macro-body"><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 sh
 ape="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 &gt; 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="dea
 d-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>
+</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="confluence-information-macro confluence-information-macro-information"><span class="aui-icon aui-icon-small aui-iconfont-info confluence-information-macro-icon"></span><div class="confluence-information-macro-body"><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 sh
 ape="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 &gt; 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="dea
 d-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><li><a shape="rect" href="load-balancer.html">Failover Load Balancer</a></li></ul></div>
         </td>
         <td valign="top">
           <div class="navigation">