camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lampis Flavio <Flavio.Lam...@zkb.ch>
Subject AW: onException does not kick in, redelivery does not work with TransactionErrorHandler
Date Fri, 11 Jan 2013 15:18:18 GMT
Hi

It seems that the onExceptions only kick in when I use the JMS TransactionErrorHandler in
the routes, e.g.:
<route id="optimisticLockA" errorHandlerRef="eh_jms">
and JPA transactions in the route:
<transacted ref="jpaPROPAGATION_REQUIRED" />

But the redelivery does not work anyway. I don't see a difference between defining the onException
in the routes or globally in the Camel Context.

Error and transaction handling is hard.

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.ibsen@gmail.com]
Gesendet: Donnerstag, 10. Januar 2013 12:57
An: users@camel.apache.org
Betreff: Re: onException does not kick in, redelivery does not work with TransactionErrorHandler

On Thu, Jan 10, 2013 at 12:49 PM, Lampis Flavio <Flavio.Lampis@zkb.ch> wrote:
> Hi Claus
>
> We're using these Versions
>
> Camel: 2.10.3
> Spring: 3.0.7.RELEASE

I think we fixed something related to context scoped onException.
Can you try defining them per route, instead of context scoped, as a workaround.

And you are welcome to test with the 2.10-SNAPSHOT or 2.11-SNAPSHOT.



>
> 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.ibsen@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.Lampis@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-07164
>> 5
>> 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: cibsen@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.



--
Claus Ibsen
-----------------
Red Hat, Inc.
FuseSource is now part of Red Hat
Email: cibsen@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.

Mime
View raw message