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 >
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 >
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">
