Hi Claus We're using these Versions
Camel: 2.10.3 Spring: 3.0.7.RELEASE Kind regards, Flavio Freundliche Grüsse Flavio Lampis LIBSR Sie drucken diese E-Mail nicht aus? Die Umwelt dankt! -----Ursprüngliche Nachricht----- Von: Claus Ibsen [mailto:claus.ib...@gmail.com] Gesendet: Donnerstag, 10. Januar 2013 11:48 An: users@camel.apache.org Betreff: Re: onException does not kick in, redelivery does not work with TransactionErrorHandler Hi What Camel version do you use? And have you tried with a newer release? On Thu, Jan 10, 2013 at 11:27 AM, Lampis Flavio <flavio.lam...@zkb.ch> wrote: > Hello Camel users > > I am new to this forum / mailing list. > > We are experiencing problems in our project with the combination of onError > and TransactionErrorHandler. Our set up is a bit complicated. I hope you read > through anyway. > > We want to distinguish between recoverable and nonrecoverable > errors/exceptions. We want to decide in our code what's recoverable and > what's not for any Exception that occurs. > > This is the setup of our errorHandlers and onException definitions: > > ... > > <camel:camelContext streamCache="true" trace="true" > xmlns="http://camel.apache.org/schema/spring";> > > <errorHandler id="eh_jms" type="TransactionErrorHandler" > transactionTemplateRef="jmsTransactionTemplate"> > <redeliveryPolicy redeliveryDelay="3000" > maximumRedeliveries="-1" > retryAttemptedLogLevel="WARN" /> > </errorHandler> > > > <errorHandler id="eh_jpa" type="TransactionErrorHandler" > transactionTemplateRef="jpaTransactionTemplate"> > <redeliveryPolicy redeliveryDelay="3000" > maximumRedeliveries="-1" > retryAttemptedLogLevel="WARN" /> > </errorHandler> > > > <routeContextRef ref="routecontext_errorroute" /> > > <routeContextRef ref="routecontext_test_error_routes" > /> > > <onException id="onNonrecoverable"> > <exception>java.lang.Exception</exception> > <onWhen> > <method id="isNonrecoverable" > bean="myErrorBean" > method="isNonrecoverable" /> > </onWhen> > <redeliveryPolicy maximumRedeliveries="0" /> > <handled> > <constant>true</constant> > </handled> > > <to uri="direct:nonrecoverableerror" /> > </onException> > > <onException id="onRecoverable" > onRedeliveryRef="myRecoverableErrorProcessor"> > <exception>java.lang.Exception</exception> > <onWhen> > <method id="isRecoverable" bean="myErrorBean" > method="isRecoverable" /> > </onWhen> > <redeliveryPolicy maximumRedeliveries="-1" > redeliveryDelay="2000" logStackTrace="false" > retryAttemptedLogLevel="WARN" > backOffMultiplier="2" > useExponentialBackOff="true" /> > </onException> > > ... > > </camel:camelContext> > > We have transacted routes - jms and jpa. Therefore we have defined two > TransactionErrorHandler with different transactionTemplates. > The first onException definition calls myErrorBean.isNonrecoverable() which > returns true or false. > The second onException definition calls myErrorBean.isRecoverable(), which > returns the opposite of isNonRecoverable. > I always expect one onException definition to kick in. And it ususally does > e.g. for this test route: > > <route id="fromJMS1ToExceptionThrowingBean" > errorHandlerRef="eh_jms"> > <from > > uri="jms:queue:{{routes.general.queue.1}}?selector=someSelector" /> > <transacted ref="jmsPROPAGATION_REQUIRED" /> > <to > uri="bean:myExceptionThrowingBean?method=throwException" /> > <log message="end fromJMS1ToExceptionThrowingBean" /> > </route> > > myExceptionThrowingBean is a simple bean which I can configure: how many > times to throw an exception, what exception to throw etc. > > With the route optimisticLockMulticast I want to update one existing entity > on a database with two different threads and cause an optimistic lock > exception. > > <route id="optimisticLockMulticast" errorHandlerRef="eh_jpa"> > <from uri="direct:optimisticLockMulticast" /> > <multicast parallelProcessing="true"> > <to uri="direct:optimisticLockA" /> > <to uri="direct:optimisticLockB" /> > </multicast> > <log message="end optimisticLockMulticast" /> > </route> > > <route id="optimisticLockA" errorHandlerRef="eh_jpa"> > <from uri="direct:optimisticLockA" /> > <transacted ref="jpaPROPAGATION_REQUIRED" /> > <bean ref="myUpdateBean" method="updateEntity" /> > <log message="end optimisticLockA" /> > <to uri="direct:endA" /> > </route> > > <route id="optimisticLockB" errorHandlerRef="eh_jpa"> > <from uri="direct:optimisticLockB" /> > <transacted ref="jpaPROPAGATION_REQUIRED" /> > <bean ref="myUpdateBean" method="updateEntity" /> > <log message="end optimisticLockB" /> > <to uri="direct:endB" /> > </route> > > <route id="directEndA"> > <from uri="direct:endA" /> > <log message="end direct" /> > </route> > > <route id="directEndB"> > <from uri="direct:endB" /> > <log message="end direct" /> > </route> > > > The entity is merged in myUpdateBean. The framework is not able to commit > both transactions as expected. That is a good thing, because this is the > behaviour we are trying to test. > This is what I see in the log: > > The first Transaction could be committed: > 08:08:07.166 [Thread-7] DEBUG TransactionErrorHandler - Transaction > commit (0x1fdbe17) redelivered(unknown) for (MessageId: > ID-MOB10086289-62103-1357628876915-0-3 on ExchangeId: > ID-MOB10086289-62103-1357628876915-0-1)) > > The second could not be committed: > 08:08:07.166 [Thread-6] WARN TransactionErrorHandler - Transaction > rollback (0x1fdbe17) redelivered(unknown) for (MessageId: > ID-MOB10086289-62103-1357628876915-0-3 on ExchangeId: > ID-MOB10086289-62103-1357628876915-0-1) > caught: Object of class [com.mycompany.model.MyModelEntityClass] with > identifier [103ace6d-19de-4dd4-b305-0716456e644f]: optimistic locking > failed; nested exception is org.hibernate.StaleObjectStateException: > Row was updated or deleted by another transaction (or unsaved-value > mapping was incorrect): > [com.mycompany.model.MyModelEntityClass#103ace6d-19de-4dd4-b305-071645 > 6e644f] > > And now at last we come to the problems: No redelivery occurs and no > onException kicks in. The exchange seems to end here. In other scenarios it > works. > > In the documentation on http://camel.apache.org/error-handler.html: > "Exception Clause > Using Error Handler combined with Exception Clause is a very powerful > combination. We encourage end-users to use this combination in your error > handling strategies. See samples and Exception Clause." > > But who is doing the rollback if an onException(MyTechnicalException) kicks > in? > > I hope I could make the problem clear and that someone might help. Thank you. > > Kindest regards, Flavio > > Freundliche Grüsse > Flavio Lampis > LIBSR > > Zürcher Kantonalbank, Geschäftshaus Hard F > Briefadresse: Postfach, 8010 Zürich / www.zkb.ch > > Sie drucken diese E-Mail nicht aus? Die Umwelt dankt! > > > > ________________________________ > > Disclaimer : > > > Diese Mitteilung ist nur für die Empfängerin / den Empfänger bestimmt. > > Für den Fall, dass sie von nichtberechtigten Personen empfangen wird, bitten > wir diese höflich, die Mitteilung an die Zürcher Kantonalbank zurückzusenden > und anschliessend die Mitteilung mit allen Anhängen sowie allfällige Kopien > zu vernichten bzw. zu löschen. Der Gebrauch der Information ist verboten. > > > This message is intended only for the named recipient and may contain > confidential or privileged information. > > If you have received it in error, please advise the sender by return e-mail > and delete this message and any attachments. Any unauthorised use or > dissemination of this information is strictly prohibited. -- Claus Ibsen ----------------- Red Hat, Inc. FuseSource is now part of Red Hat Email: cib...@redhat.com Web: http://fusesource.com Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen ________________________________ Disclaimer : Diese Mitteilung ist nur für die Empfängerin / den Empfänger bestimmt. Für den Fall, dass sie von nichtberechtigten Personen empfangen wird, bitten wir diese höflich, die Mitteilung an die Zürcher Kantonalbank zurückzusenden und anschliessend die Mitteilung mit allen Anhängen sowie allfällige Kopien zu vernichten bzw. zu löschen. Der Gebrauch der Information ist verboten. This message is intended only for the named recipient and may contain confidential or privileged information. If you have received it in error, please advise the sender by return e-mail and delete this message and any attachments. Any unauthorised use or dissemination of this information is strictly prohibited.
