You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Fush <ri...@gmail.com> on 2008/11/18 17:06:09 UTC
1.5 error handling Spring config buggy/not complete?
Hi! Below is a snippet of my camel route/xml. As you can see, I'm trying to
set up some transaction and error handling there. But I've ran into a couple
of strange issues. Are these known? Can anyone here explain them?
1. Even if the exception thrown by myBean is a TechnicalException (ie. not a
FunctionalException), the method on the myOwnErrorHandler bean is invoked.
How can that happen?
2. Even if maximumRedeliveries is set to 0, for the two onException clauses,
as well as in the redeliveryPolicyConfig, the message is redelivered 5 times
(as default) when an exception occurs. Why are my settings of 0 not read?
3. Based on the above, can you spot any obvious errors in my configurations?
Or should I assume the spring interpretation to be flawed?
Here's the important part of my XML:
<camelContext id="myRouting"
xmlns="http://activemq.apache.org/camel/schema/spring">
<route errorHandlerRef="transactionErrorHandler">
<from uri="activemq:queue/myQueue/aQueue" />
<!-- <policy ref="required"/>-->
<choice>
<when>
<xpath>//type = 'myType'</xpath>
<onException>
<exception>org.my.exception.TechnicalException
</exception>
<redeliveryPolicy maximumRedeliveries="0" />
<handled>
<constant>true</constant>
</handled>
<!-- ANY SPECIFIC HANDLING HERE? -->
</onException>
<onException>
<exception>org.my.exception.FunctionalException
</exception>
<redeliveryPolicy maximumRedeliveries="0" />
<handled>
<constant>true</constant>
</handled>
<to uri="bean:myOwnErrorHandler" />
</onException>
<unmarshal>
<jaxb prettyPrint="true" contextPath="org.my.domain.message" />
</unmarshal>
<to uri="bean:myBean" />
</when>
</choice>
</route>
</camelContext>
<bean id="jmsTransactionManager"
class="org.springframework.jms.connection.JmsTransactionManager">
<property name="connectionFactory" ref="jmsConnectionFactory" />
</bean>
<bean id="jmsConnectionFactory"
class="org.apache.activemq.ActiveMQConnectionFactory">
<property name="brokerURL" value="${org.my.activemq.url}"/>
</bean>
<bean id="jmsConfig"
class="org.apache.camel.component.jms.JmsConfiguration">
<property name="connectionFactory" ref="jmsConnectionFactory"/>
<property name="transactionManager" ref="jmsTransactionManager"/>
<property name="transacted" value="true"/>
<property name="concurrentConsumers" value="1"/>
</bean>
<!-- camel policy we refer to in our route -->
<bean id="required"
class="org.apache.camel.spring.spi.SpringTransactionPolicy">
<property name="template" ref="PROPAGATION_REQUIRED"/>
</bean>
<!-- the standard spring transaction template for required -->
<bean id="PROPAGATION_REQUIRED"
class="org.springframework.transaction.support.TransactionTemplate">
<property name="transactionManager" ref="jmsTransactionManager"/>
</bean>
<!-- the transaction error handler we refer to from the route -->
<bean id="transactionErrorHandler"
class="org.apache.camel.spring.spi.TransactionErrorHandlerBuilder">
<property name="transactionTemplate" ref="PROPAGATION_REQUIRED"/>
<!-- here we refer to the configurations of the error handler -->
<property name="delayPolicy" ref="redeliveryPolicyConfig"/>
</bean>
<!-- configuration of the transaction error handler -->
<bean id="redeliveryPolicyConfig"
class="org.apache.camel.processor.RedeliveryPolicy">
<property name="delay" value="5000"/>
<property name="maximumRedeliveries" value="0"/>
</bean>
<!-- ActiveMQ instance -->
<bean id="activemq" class="org.apache.camel.component.jms.JmsComponent">
<property name="configuration" ref="jmsConfig"/>
</bean>
<bean id="myOwnErrorHandler" class="org.my.beans.MyErrorHandler"/>
<bean id="myBean" class="org.my.beans.MyBean"/>
--
View this message in context: http://www.nabble.com/1.5-error-handling-Spring-config-buggy-not-complete--tp20562554s22882p20562554.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: 1.5 error handling Spring config buggy/not complete?
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
me again
To configure the redelivey settings in ActiveMQ you should turn to
it's documentation.
A good idea is to use the input search field and type: redelivery.
Then you get google search and can find links:
http://activemq.apache.org/redelivery-policy.html
There might be a better wiki documentation page explaining this for ActiceMQ.
>From the link above you can configure it as URI options for the
ActiveMQ brooker.
/Claus Ibsen
Apache Camel Committer
Blog: http://davsclaus.blogspot.com/
On Wed, Nov 19, 2008 at 8:18 AM, Claus Ibsen <cl...@gmail.com> wrote:
> Hi
>
> a)
> Ah that might not be clearly stated in the documentation.
>
> It's an *all* or *nothing* with transactions. If using transactions
> then it's the backing system (the transaction manger) responsibility
> to handle redelivery - not Camel. Camel in this case only supports
> delaying a fixed delay before the rollback is triggered.
>
> And as you use ActiveMQ as the backing system it is the ActiveMQ
> transaction manger that handles the redelivery. And it uses 5 or is it
> 6 redeliveries by default. So you should configure ActiveMQ how
> redelivery should be done.
>
>
> b)
> That said I turn to the onException
>
> Is TechnicalException and FunctionalException related as such one is
> inherited from the other?
> eg: FunctionalException extends TechnicalException ?
>
> Camel uses (by default) an instanceof test to verify which onException
> should handle the exception.
>
> You might have a use-case using transactions and onException that
> needs to be checked
> - You have onExceptions that also is meent to supoorts catch exception
> this exception and route it differently. And then you can have the
> handled=true to state it's okay, newer mind the exception I have
> handled it and the TX = OK.
> - But it can also be used as a if this exception is thrown then only
> retry 2 times instead of default 5 times etc.
> - etc.
>
> c)
> In any case it should really only call the myOwnErrorHandler only for
> the FunctionalException.
>
> I will check up on your spring XML and add it as a unit test in camel.
>
>
>
> /Claus Ibsen
> Apache Camel Committer
> Blog: http://davsclaus.blogspot.com/
>
>
>
> On Tue, Nov 18, 2008 at 5:06 PM, Fush <ri...@gmail.com> wrote:
>>
>> Hi! Below is a snippet of my camel route/xml. As you can see, I'm trying to
>> set up some transaction and error handling there. But I've ran into a couple
>> of strange issues. Are these known? Can anyone here explain them?
>>
>> 1. Even if the exception thrown by myBean is a TechnicalException (ie. not a
>> FunctionalException), the method on the myOwnErrorHandler bean is invoked.
>> How can that happen?
>> 2. Even if maximumRedeliveries is set to 0, for the two onException clauses,
>> as well as in the redeliveryPolicyConfig, the message is redelivered 5 times
>> (as default) when an exception occurs. Why are my settings of 0 not read?
>> 3. Based on the above, can you spot any obvious errors in my configurations?
>> Or should I assume the spring interpretation to be flawed?
>>
>> Here's the important part of my XML:
>>
>> <camelContext id="myRouting"
>> xmlns="http://activemq.apache.org/camel/schema/spring">
>> <route errorHandlerRef="transactionErrorHandler">
>> <from uri="activemq:queue/myQueue/aQueue" />
>> <!-- <policy ref="required"/>-->
>> <choice>
>> <when>
>> <xpath>//type = 'myType'</xpath>
>> <onException>
>> <exception>org.my.exception.TechnicalException
>> </exception>
>> <redeliveryPolicy maximumRedeliveries="0" />
>> <handled>
>> <constant>true</constant>
>> </handled>
>> <!-- ANY SPECIFIC HANDLING HERE? -->
>> </onException>
>> <onException>
>> <exception>org.my.exception.FunctionalException
>> </exception>
>> <redeliveryPolicy maximumRedeliveries="0" />
>> <handled>
>> <constant>true</constant>
>> </handled>
>> <to uri="bean:myOwnErrorHandler" />
>> </onException>
>> <unmarshal>
>> <jaxb prettyPrint="true" contextPath="org.my.domain.message" />
>> </unmarshal>
>> <to uri="bean:myBean" />
>> </when>
>> </choice>
>> </route>
>> </camelContext>
>>
>> <bean id="jmsTransactionManager"
>> class="org.springframework.jms.connection.JmsTransactionManager">
>> <property name="connectionFactory" ref="jmsConnectionFactory" />
>> </bean>
>>
>> <bean id="jmsConnectionFactory"
>> class="org.apache.activemq.ActiveMQConnectionFactory">
>> <property name="brokerURL" value="${org.my.activemq.url}"/>
>> </bean>
>>
>> <bean id="jmsConfig"
>> class="org.apache.camel.component.jms.JmsConfiguration">
>> <property name="connectionFactory" ref="jmsConnectionFactory"/>
>> <property name="transactionManager" ref="jmsTransactionManager"/>
>> <property name="transacted" value="true"/>
>> <property name="concurrentConsumers" value="1"/>
>> </bean>
>>
>> <!-- camel policy we refer to in our route -->
>> <bean id="required"
>> class="org.apache.camel.spring.spi.SpringTransactionPolicy">
>> <property name="template" ref="PROPAGATION_REQUIRED"/>
>> </bean>
>>
>> <!-- the standard spring transaction template for required -->
>> <bean id="PROPAGATION_REQUIRED"
>> class="org.springframework.transaction.support.TransactionTemplate">
>> <property name="transactionManager" ref="jmsTransactionManager"/>
>> </bean>
>>
>> <!-- the transaction error handler we refer to from the route -->
>> <bean id="transactionErrorHandler"
>> class="org.apache.camel.spring.spi.TransactionErrorHandlerBuilder">
>> <property name="transactionTemplate" ref="PROPAGATION_REQUIRED"/>
>> <!-- here we refer to the configurations of the error handler -->
>> <property name="delayPolicy" ref="redeliveryPolicyConfig"/>
>> </bean>
>>
>> <!-- configuration of the transaction error handler -->
>> <bean id="redeliveryPolicyConfig"
>> class="org.apache.camel.processor.RedeliveryPolicy">
>> <property name="delay" value="5000"/>
>> <property name="maximumRedeliveries" value="0"/>
>> </bean>
>>
>> <!-- ActiveMQ instance -->
>> <bean id="activemq" class="org.apache.camel.component.jms.JmsComponent">
>> <property name="configuration" ref="jmsConfig"/>
>> </bean>
>>
>> <bean id="myOwnErrorHandler" class="org.my.beans.MyErrorHandler"/>
>>
>> <bean id="myBean" class="org.my.beans.MyBean"/>
>> --
>> View this message in context: http://www.nabble.com/1.5-error-handling-Spring-config-buggy-not-complete--tp20562554s22882p20562554.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>
>>
>
Re: 1.5 error handling Spring config buggy/not complete?
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
As a spare time camel rider I will have time to look into this in the
weekend where it's supposed to be cold weather.
So I will look into it at that time. Now I have the laptop on my lap
and cant really do coding ;)
Ad 1)
Yes I think you can do this.
BTW you can also use seda queus instead of JMS queues. See seda on the
camel component overview.
Ad 2)
I do think it should be possible if you write your own exception
policy where you can do the enum test as well.
But what you is looking for is to attach a predicate to the
onException where you can do the extra test
Something like this,
onException(MyTechnicalException.class).when("bean:hasSpecialEnum).
So the onException is only triggered if the preidicate passes as well.
But I guess you could do this with a content based router (choice) and
using a bean to test the condition
onException(MyTechnicalException.class)
.choice()
.when("bean:hasSpecialEnumTester").
.to("bean:specialHandling")
.otherwise().to("bean:normalHandling");
I doubt we have something that can test if a class has an enum as a
DSL so use a bean.
You can get the exception using
public class MySpecialEnumTester
public boolean hasEnum(Exchange exchange) {
Exception e = exchange.getExchange();
// test for enum
return true or false
}
}
/Claus Ibsen
Apache Camel Committer
Blog: http://davsclaus.blogspot.com/
On Wed, Nov 19, 2008 at 4:20 PM, Fush <ri...@gmail.com> wrote:
>
>
> Claus Ibsen-2 wrote:
>>
>> Sort of. I am about to leave the office, but you have a very
>> interesting use-case that I need to dig into. If time permits I will
>> be online tonight.
>>
>> You can define your own exception policy strategy:
>> http://activemq.apache.org/camel/error-handler.html
>>
>> That is the policy to determine which onException should be triggered.
>>
>> But to get it clear.
>> If your bean myOwnErrorHandler throws an exception what do you want to
>> happen?
>> If myOwnErrorHandler throws an exception, I want the same thing to happen
>> as with any other exception than FunctionalException. For my use case,
>> that means a certain number of redeliveries and a certain delay time, and
>> is defined by the redeliveryPolicyConfig bean.
>
> But I've now chosen to solve this by using an extra queue. So in case of a
> FunctionalException, instead of routing the message to myOwnErrorHandler,
> I'll route the message to myOwnErrorQueue. And I'll set up a new route that
> listens to myOwnErrorQueue, which will route any message from that queue to
> myOwnErrorHandler. That way, any exceptions thrown by myOwnErrorHandler will
> be handled by the same policy that's set up for the
> ActiveMQConnectionFactory. How does that sound to you?
>
> Still, I have these to issues to resolve:
> 1. The onException part seems to be triggered, even if the Exception is not
> a FunctionalException. I'm curious about if that's a bug, or if there's
> something wrong with my configuration.
> 2. The onException should ideally not just check the exception type, but
> also an Enum within the exception, indicating an error code, before deciding
> if it needs "special treatment". As far as I can tell, that's not supported
> by the Camel XML.
> --
> View this message in context: http://www.nabble.com/1.5-error-handling-Spring-config-buggy-not-complete--tp20562554s22882p20582041.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
Re: 1.5 error handling Spring config buggy/not complete?
Posted by Fush <ri...@gmail.com>.
Claus Ibsen-2 wrote:
>
> Sort of. I am about to leave the office, but you have a very
> interesting use-case that I need to dig into. If time permits I will
> be online tonight.
>
> You can define your own exception policy strategy:
> http://activemq.apache.org/camel/error-handler.html
>
> That is the policy to determine which onException should be triggered.
>
> But to get it clear.
> If your bean myOwnErrorHandler throws an exception what do you want to
> happen?
> If myOwnErrorHandler throws an exception, I want the same thing to happen
> as with any other exception than FunctionalException. For my use case,
> that means a certain number of redeliveries and a certain delay time, and
> is defined by the redeliveryPolicyConfig bean.
But I've now chosen to solve this by using an extra queue. So in case of a
FunctionalException, instead of routing the message to myOwnErrorHandler,
I'll route the message to myOwnErrorQueue. And I'll set up a new route that
listens to myOwnErrorQueue, which will route any message from that queue to
myOwnErrorHandler. That way, any exceptions thrown by myOwnErrorHandler will
be handled by the same policy that's set up for the
ActiveMQConnectionFactory. How does that sound to you?
Still, I have these to issues to resolve:
1. The onException part seems to be triggered, even if the Exception is not
a FunctionalException. I'm curious about if that's a bug, or if there's
something wrong with my configuration.
2. The onException should ideally not just check the exception type, but
also an Enum within the exception, indicating an error code, before deciding
if it needs "special treatment". As far as I can tell, that's not supported
by the Camel XML.
--
View this message in context: http://www.nabble.com/1.5-error-handling-Spring-config-buggy-not-complete--tp20562554s22882p20582041.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: 1.5 error handling Spring config buggy/not complete?
Posted by Claus Ibsen <cl...@gmail.com>.
On Wed, Nov 19, 2008 at 1:33 PM, Fush <ri...@gmail.com> wrote:
>
> I was assuming that if an exception (any other than FunctionalException) was
> thrown from within my <onException> clause, it would be handled by the
> TransactionManager as for all other exceptions. But apparently not. :)
>
> I have to expect exceptions from the myOwnErrorHandler bean, because it
> calls a remote system. What are my options if I would like to write my own
> implementation of the <onException> tag? Would that be feasible? Do you know
> of any examples/tutorials for that?
Sort of. I am about to leave the office, but you have a very
interesting use-case that I need to dig into. If time permits I will
be online tonight.
You can define your own exception policy strategy:
http://activemq.apache.org/camel/error-handler.html
That is the policy to determine which onException should be triggered.
But to get it clear.
If your bean myOwnErrorHandler throws an exception what do you want to happen?
>
>
> Claus Ibsen-2 wrote:
>>
>> Hi
>>
>> Ha ha you have a catch-22 situation ;) You are doing the "handling" of
>> the exception (kinda like a finally) but in that process you also have
>> an exception being thrown.
>>
>> What would be the ideal situation to do here?
>> - Let Camel try to find a new onException that matches the new
>> exception being thrown?
>> - Or log it as a kind of WARN (this is the easiest to do)
>>
>> We should beware that we don't push the it to far and it gets to
>> complex to understand what happens.
>>
>> Any thoughts?
>>
>>
>> A workaround in your bean is to use
>> try .. catch code style and handle the new exception your self.
>>
>>
>> /Claus Ibsen
>> Apache Camel Committer
>> Blog: http://davsclaus.blogspot.com/
>>
>
> --
> View this message in context: http://www.nabble.com/1.5-error-handling-Spring-config-buggy-not-complete--tp20562554s22882p20578887.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
Re: 1.5 error handling Spring config buggy/not complete?
Posted by Fush <ri...@gmail.com>.
I was assuming that if an exception (any other than FunctionalException) was
thrown from within my <onException> clause, it would be handled by the
TransactionManager as for all other exceptions. But apparently not. :)
I have to expect exceptions from the myOwnErrorHandler bean, because it
calls a remote system. What are my options if I would like to write my own
implementation of the <onException> tag? Would that be feasible? Do you know
of any examples/tutorials for that?
Claus Ibsen-2 wrote:
>
> Hi
>
> Ha ha you have a catch-22 situation ;) You are doing the "handling" of
> the exception (kinda like a finally) but in that process you also have
> an exception being thrown.
>
> What would be the ideal situation to do here?
> - Let Camel try to find a new onException that matches the new
> exception being thrown?
> - Or log it as a kind of WARN (this is the easiest to do)
>
> We should beware that we don't push the it to far and it gets to
> complex to understand what happens.
>
> Any thoughts?
>
>
> A workaround in your bean is to use
> try .. catch code style and handle the new exception your self.
>
>
> /Claus Ibsen
> Apache Camel Committer
> Blog: http://davsclaus.blogspot.com/
>
--
View this message in context: http://www.nabble.com/1.5-error-handling-Spring-config-buggy-not-complete--tp20562554s22882p20578887.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: 1.5 error handling Spring config buggy/not complete?
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
Ha ha you have a catch-22 situation ;) You are doing the "handling" of
the exception (kinda like a finally) but in that process you also have
an exception being thrown.
What would be the ideal situation to do here?
- Let Camel try to find a new onException that matches the new
exception being thrown?
- Or log it as a kind of WARN (this is the easiest to do)
We should beware that we don't push the it to far and it gets to
complex to understand what happens.
Any thoughts?
A workaround in your bean is to use
try .. catch code style and handle the new exception your self.
/Claus Ibsen
Apache Camel Committer
Blog: http://davsclaus.blogspot.com/
On Wed, Nov 19, 2008 at 1:13 PM, Fush <ri...@gmail.com> wrote:
>
> Thanks for looking into it. I've come across one more behavior, that I don't
> quite understand: Given the route below, if the method in myOwnErrorHandler
> throws an exception (ie my own errorhandling fails), the message is
> redelivered 5 times. Can this be configured somehow (where), or am I
> supposed to handle this manually in the myOwnErrorHandler bean? Basically,
> what are my options for configuring and/or manually implementing the
> <onException> handling? I can't seem to find much documentation/examples for
> it.
>
> <camelContext id="myRouting"
> xmlns="http://activemq.apache.org/camel/schema/spring">
> <route>
> <from uri="activemq:queue/myQueue/aQueue" />
> <choice>
> <when>
> <xpath>//type = 'myType'</xpath>
> <onException>
>
> <exception>org.my.exception.FunctionalException
> </exception>
> <redeliveryPolicy
> maximumRedeliveries="0" />
> <handled>
> <constant>true</constant>
> </handled>
> <to uri="bean:myOwnErrorHandler" />
> </onException>
> <unmarshal>
> <jaxb prettyPrint="true"
> contextPath="org.my.domain.message" />
> </unmarshal>
> <to uri="bean:myBean" />
> </when>
> </choice>
> </route>
> </camelContext>
> --
> View this message in context: http://www.nabble.com/1.5-error-handling-Spring-config-buggy-not-complete--tp20562554s22882p20578586.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
Re: 1.5 error handling Spring config buggy/not complete?
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
I had a go on this today and added the when expression so you can do
the enum test and in case it returns false not go with this
onException.
Somehting like this is now possible:
<onException>
<exception>com.mycompany.MyFunctionalException</exception>
<onWhen><methodCall bean="xxx" method="hasSpecialEnum"/></onWhen>
<redeliveryPolicy maximumRedeliveries="0"/>
<handled><constant>true</constant></handled>
<to uri="jms:queue:myspecialqueue"/>
</onException>
PS: It's currently only committed to Camel 2.0 will move it to 1.5.1
after the documentation has been polished.
/Claus Ibsen
Apache Camel Committer
Blog: http://davsclaus.blogspot.com/
On Fri, Nov 21, 2008 at 9:56 AM, Claus Ibsen <cl...@gmail.com> wrote:
> Hi
>
> Yeah the TX stuff does the final rollback or commit. But you have
> surfaced an use-case where using TX but with routes with the
> onException might be a valid point, so you can use both (TX +
> onException) but not redelivery as this is done by the TX manager.
> And also the onException could "reset the exception flag" so there
> wont be a TX rollback.
>
> So using TX but still want to use onException for eg. taking a detour
> in the route path should maybe be possible. As said in previous mails
> in this thread there is much stuff for investigations and debate as
> well ;)
>
> Maybe if you have the time could rewrite your requirements and some
> descriptions what should happen in the various situations when an
> exception occur. It would help when/if we improve Camel in this area
> and you make sure your use-case is better supported out-of-the-box.
>
>
> /Claus Ibsen
> Apache Camel Committer
> Blog: http://davsclaus.blogspot.com/
>
>
>
> On Fri, Nov 21, 2008 at 9:42 AM, Fush <ri...@gmail.com> wrote:
>>
>> Thanks again for following this up. I'll be watching the Jira issue.
>>
>> Regarding writing my own error handler, that is a tempting option. But you
>> also said that when using transactions, it's "all or nothing". I still want
>> to use transactions, to make sure messages are not removed from the queue
>> before they are handled correctly. So that would prevent me from using my
>> own Camel error handler, right?
>>
>> Claus Ibsen-2 wrote:
>>>
>>> Hi
>>>
>>> #1 + #2
>>> Yeah you have a use case that is a bit more advanced. I have created a
>>> ticket to make it easier to attach a predicate to the onException so
>>> you can do your custom test here also before the onexception is
>>> triggered.
>>> http://issues.apache.org/activemq/browse/CAMEL-1104
>>>
>>> You could however write your own customized exception policy strategy:
>>> http://activemq.apache.org/camel/error-handler.html
>>>
>>> Camel has a default strategy that is used to find the matching
>>> exception thrown in the list of onException tags.
>>>
>>> There is a sample on the link above. Basically what you have to do is
>>> to find the matching onException to use from the given map of
>>> exception types. The last parameter is the actual exception thrown.
>>>
>>> So if the last exception is your special exception you can do the enum
>>> test and find the correct onException from the map, and return it.
>>>
>>> I am afraid the sample is for Java DSL so you could try to see if you
>>> can get it to work in Spring DSL as well. Let me know how it goes.
>>>
>>>
>>> /Claus Ibsen
>>> Apache Camel Committer
>>> Blog: http://davsclaus.blogspot.com/
>>>
>>
>> --
>> View this message in context: http://www.nabble.com/1.5-error-handling-Spring-config-buggy-not-complete--tp20562554s22882p20617200.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>
>>
>
Re: 1.5 error handling Spring config buggy/not complete?
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
Yeah the TX stuff does the final rollback or commit. But you have
surfaced an use-case where using TX but with routes with the
onException might be a valid point, so you can use both (TX +
onException) but not redelivery as this is done by the TX manager.
And also the onException could "reset the exception flag" so there
wont be a TX rollback.
So using TX but still want to use onException for eg. taking a detour
in the route path should maybe be possible. As said in previous mails
in this thread there is much stuff for investigations and debate as
well ;)
Maybe if you have the time could rewrite your requirements and some
descriptions what should happen in the various situations when an
exception occur. It would help when/if we improve Camel in this area
and you make sure your use-case is better supported out-of-the-box.
/Claus Ibsen
Apache Camel Committer
Blog: http://davsclaus.blogspot.com/
On Fri, Nov 21, 2008 at 9:42 AM, Fush <ri...@gmail.com> wrote:
>
> Thanks again for following this up. I'll be watching the Jira issue.
>
> Regarding writing my own error handler, that is a tempting option. But you
> also said that when using transactions, it's "all or nothing". I still want
> to use transactions, to make sure messages are not removed from the queue
> before they are handled correctly. So that would prevent me from using my
> own Camel error handler, right?
>
> Claus Ibsen-2 wrote:
>>
>> Hi
>>
>> #1 + #2
>> Yeah you have a use case that is a bit more advanced. I have created a
>> ticket to make it easier to attach a predicate to the onException so
>> you can do your custom test here also before the onexception is
>> triggered.
>> http://issues.apache.org/activemq/browse/CAMEL-1104
>>
>> You could however write your own customized exception policy strategy:
>> http://activemq.apache.org/camel/error-handler.html
>>
>> Camel has a default strategy that is used to find the matching
>> exception thrown in the list of onException tags.
>>
>> There is a sample on the link above. Basically what you have to do is
>> to find the matching onException to use from the given map of
>> exception types. The last parameter is the actual exception thrown.
>>
>> So if the last exception is your special exception you can do the enum
>> test and find the correct onException from the map, and return it.
>>
>> I am afraid the sample is for Java DSL so you could try to see if you
>> can get it to work in Spring DSL as well. Let me know how it goes.
>>
>>
>> /Claus Ibsen
>> Apache Camel Committer
>> Blog: http://davsclaus.blogspot.com/
>>
>
> --
> View this message in context: http://www.nabble.com/1.5-error-handling-Spring-config-buggy-not-complete--tp20562554s22882p20617200.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
Re: 1.5 error handling Spring config buggy/not complete?
Posted by Fush <ri...@gmail.com>.
Thanks again for following this up. I'll be watching the Jira issue.
Regarding writing my own error handler, that is a tempting option. But you
also said that when using transactions, it's "all or nothing". I still want
to use transactions, to make sure messages are not removed from the queue
before they are handled correctly. So that would prevent me from using my
own Camel error handler, right?
Claus Ibsen-2 wrote:
>
> Hi
>
> #1 + #2
> Yeah you have a use case that is a bit more advanced. I have created a
> ticket to make it easier to attach a predicate to the onException so
> you can do your custom test here also before the onexception is
> triggered.
> http://issues.apache.org/activemq/browse/CAMEL-1104
>
> You could however write your own customized exception policy strategy:
> http://activemq.apache.org/camel/error-handler.html
>
> Camel has a default strategy that is used to find the matching
> exception thrown in the list of onException tags.
>
> There is a sample on the link above. Basically what you have to do is
> to find the matching onException to use from the given map of
> exception types. The last parameter is the actual exception thrown.
>
> So if the last exception is your special exception you can do the enum
> test and find the correct onException from the map, and return it.
>
> I am afraid the sample is for Java DSL so you could try to see if you
> can get it to work in Spring DSL as well. Let me know how it goes.
>
>
> /Claus Ibsen
> Apache Camel Committer
> Blog: http://davsclaus.blogspot.com/
>
--
View this message in context: http://www.nabble.com/1.5-error-handling-Spring-config-buggy-not-complete--tp20562554s22882p20617200.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: 1.5 error handling Spring config buggy/not complete?
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
#1 + #2
Yeah you have a use case that is a bit more advanced. I have created a
ticket to make it easier to attach a predicate to the onException so
you can do your custom test here also before the onexception is
triggered.
http://issues.apache.org/activemq/browse/CAMEL-1104
You could however write your own customized exception policy strategy:
http://activemq.apache.org/camel/error-handler.html
Camel has a default strategy that is used to find the matching
exception thrown in the list of onException tags.
There is a sample on the link above. Basically what you have to do is
to find the matching onException to use from the given map of
exception types. The last parameter is the actual exception thrown.
So if the last exception is your special exception you can do the enum
test and find the correct onException from the map, and return it.
I am afraid the sample is for Java DSL so you could try to see if you
can get it to work in Spring DSL as well. Let me know how it goes.
/Claus Ibsen
Apache Camel Committer
Blog: http://davsclaus.blogspot.com/
On Thu, Nov 20, 2008 at 3:40 PM, Fush <ri...@gmail.com> wrote:
>
> Yeah, I've now moved the onException to right after the <from> tag. It looks
> like this:
>
> <onException>
> <exception>org.my.exception.FunctionalException</exception>
> <redeliveryPolicy maximumRedeliveries="0" />
> <choice>
> <when>
> <methodCall bean="myOwnErrorHandler" method="hasSpecialEnumCode"/>
> <handled>
> <constant>true</constant>
> </handled>
> <to uri="activemq:queue/myQueue/myFunctionalErrorQueue"/>
> </when>
> <otherwise/>
> </choice>
> </onException>
>
> But there are two problems with this:
> 1. The <handled> tag can't be inside the <when> tags.
> 2. If the <methodCall> resolves to false (ie the special enum is not found,
> and the <otherwise> tag is entered), I would like the normal
> redeliveryPolicy set on the jmsConnectionFactory to kick in and handle the
> exception (ie with delay/redeliveries). But with the present configuration,
> it seems like I must implement some error handling within the <otherwise>,
> right?
>
>
> Claus Ibsen-2 wrote:
>>
>> Hi
>>
>> Could you try to move the onException outside the from tag?
>>
>> It should be like this:
>>
>> <route>
>> <onException>
>> </onException
>> <from>
>> ...
>> </route>
>>
>
> --
> View this message in context: http://www.nabble.com/1.5-error-handling-Spring-config-buggy-not-complete--tp20562554s22882p20602491.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
Re: 1.5 error handling Spring config buggy/not complete?
Posted by Fush <ri...@gmail.com>.
Yeah, I've now moved the onException to right after the <from> tag. It looks
like this:
<onException>
<exception>org.my.exception.FunctionalException</exception>
<redeliveryPolicy maximumRedeliveries="0" />
<choice>
<when>
<methodCall bean="myOwnErrorHandler" method="hasSpecialEnumCode"/>
<handled>
<constant>true</constant>
</handled>
<to uri="activemq:queue/myQueue/myFunctionalErrorQueue"/>
</when>
<otherwise/>
</choice>
</onException>
But there are two problems with this:
1. The <handled> tag can't be inside the <when> tags.
2. If the <methodCall> resolves to false (ie the special enum is not found,
and the <otherwise> tag is entered), I would like the normal
redeliveryPolicy set on the jmsConnectionFactory to kick in and handle the
exception (ie with delay/redeliveries). But with the present configuration,
it seems like I must implement some error handling within the <otherwise>,
right?
Claus Ibsen-2 wrote:
>
> Hi
>
> Could you try to move the onException outside the from tag?
>
> It should be like this:
>
> <route>
> <onException>
> </onException
> <from>
> ...
> </route>
>
--
View this message in context: http://www.nabble.com/1.5-error-handling-Spring-config-buggy-not-complete--tp20562554s22882p20602491.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: 1.5 error handling Spring config buggy/not complete?
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
Could you try to move the onException outside the from tag?
It should be like this:
<route>
<onException>
</onException
<from>
...
</route>
If you enable DEBUG logging for org.apache.camel you will set that it
will try to find which onexception to use when the exception is
thrown. Something like this:
2008-11-20 11:36:57,062 [main ] DEBUG
DefaultExceptionPolicyStrategy - Finding best suited exception policy
for thrown exception
org.apache.camel.processor.onexception.MyTechnicalException
2008-11-20 11:36:57,062 [main ] DEBUG
DefaultExceptionPolicyStrategy - Using Exception[[class
org.apache.camel.processor.onexception.MyTechnicalException] -> []] as
the exception policy
/Claus Ibsen
Apache Camel Committer
Blog: http://davsclaus.blogspot.com/
On Wed, Nov 19, 2008 at 1:13 PM, Fush <ri...@gmail.com> wrote:
>
> Thanks for looking into it. I've come across one more behavior, that I don't
> quite understand: Given the route below, if the method in myOwnErrorHandler
> throws an exception (ie my own errorhandling fails), the message is
> redelivered 5 times. Can this be configured somehow (where), or am I
> supposed to handle this manually in the myOwnErrorHandler bean? Basically,
> what are my options for configuring and/or manually implementing the
> <onException> handling? I can't seem to find much documentation/examples for
> it.
>
> <camelContext id="myRouting"
> xmlns="http://activemq.apache.org/camel/schema/spring">
> <route>
> <from uri="activemq:queue/myQueue/aQueue" />
> <choice>
> <when>
> <xpath>//type = 'myType'</xpath>
> <onException>
>
> <exception>org.my.exception.FunctionalException
> </exception>
> <redeliveryPolicy
> maximumRedeliveries="0" />
> <handled>
> <constant>true</constant>
> </handled>
> <to uri="bean:myOwnErrorHandler" />
> </onException>
> <unmarshal>
> <jaxb prettyPrint="true"
> contextPath="org.my.domain.message" />
> </unmarshal>
> <to uri="bean:myBean" />
> </when>
> </choice>
> </route>
> </camelContext>
> --
> View this message in context: http://www.nabble.com/1.5-error-handling-Spring-config-buggy-not-complete--tp20562554s22882p20578586.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
Re: 1.5 error handling Spring config buggy/not complete?
Posted by Fush <ri...@gmail.com>.
Thanks for looking into it. I've come across one more behavior, that I don't
quite understand: Given the route below, if the method in myOwnErrorHandler
throws an exception (ie my own errorhandling fails), the message is
redelivered 5 times. Can this be configured somehow (where), or am I
supposed to handle this manually in the myOwnErrorHandler bean? Basically,
what are my options for configuring and/or manually implementing the
<onException> handling? I can't seem to find much documentation/examples for
it.
<camelContext id="myRouting"
xmlns="http://activemq.apache.org/camel/schema/spring">
<route>
<from uri="activemq:queue/myQueue/aQueue" />
<choice>
<when>
<xpath>//type = 'myType'</xpath>
<onException>
<exception>org.my.exception.FunctionalException
</exception>
<redeliveryPolicy
maximumRedeliveries="0" />
<handled>
<constant>true</constant>
</handled>
<to uri="bean:myOwnErrorHandler" />
</onException>
<unmarshal>
<jaxb prettyPrint="true"
contextPath="org.my.domain.message" />
</unmarshal>
<to uri="bean:myBean" />
</when>
</choice>
</route>
</camelContext>
--
View this message in context: http://www.nabble.com/1.5-error-handling-Spring-config-buggy-not-complete--tp20562554s22882p20578586.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: 1.5 error handling Spring config buggy/not complete?
Posted by Claus Ibsen <cl...@gmail.com>.
Comments below
/Claus Ibsen
Apache Camel Committer
Blog: http://davsclaus.blogspot.com/
On Wed, Nov 19, 2008 at 10:30 AM, Fush <ri...@gmail.com> wrote:
>
>
> Claus Ibsen-2 wrote:
>>
>> Hi
>>
>> a)
>> Ah that might not be clearly stated in the documentation.
>>
>> It's an *all* or *nothing* with transactions. If using transactions
>> then it's the backing system (the transaction manger) responsibility
>> to handle redelivery - not Camel. Camel in this case only supports
>> delaying a fixed delay before the rollback is triggered.
>>
>> And as you use ActiveMQ as the backing system it is the ActiveMQ
>> transaction manger that handles the redelivery. And it uses 5 or is it
>> 6 redeliveries by default. So you should configure ActiveMQ how
>> redelivery should be done.
>> So, are you basically saying that I could remove the
>> transactionErrorHandler bean from the route, and just set a
>> redeliveryPolicy on the ActiveMQConnectionFactory instead?
Yeah if you want to use transacted messaging. Then you should
configure ActiveMQ how to do redelivery.
If *not* using transacted messaging you can use all the fancy stuff Camel has.
>
>
> Claus Ibsen-2 wrote:
>>
>> b)
>> That said I turn to the onException
>>
>> Is TechnicalException and FunctionalException related as such one is
>> inherited from the other?
>> eg: FunctionalException extends TechnicalException ?
>>
>> Camel uses (by default) an instanceof test to verify which onException
>> should handle the exception.
>>
>> You might have a use-case using transactions and onException that
>> needs to be checked
>> - You have onExceptions that also is meent to supoorts catch exception
>> this exception and route it differently. And then you can have the
>> handled=true to state it's okay, newer mind the exception I have
>> handled it and the TX = OK.
>> - But it can also be used as a if this exception is thrown then only
>> retry 2 times instead of default 5 times etc.
>> - etc.
>> Both exceptions extend RuntimeException, and nothing else. So there's no
>> other relationship between them.
Thanks. Will look into this that Camel should pick the correct exception.
>
>
> Claus Ibsen-2 wrote:
>>
>> c)
>> In any case it should really only call the myOwnErrorHandler only for
>> the FunctionalException.
>>
>> I will check up on your spring XML and add it as a unit test in camel.
>> I'm curious to see what you find out about this. Thanks!
>
> --
> View this message in context: http://www.nabble.com/1.5-error-handling-Spring-config-buggy-not-complete--tp20562554s22882p20576291.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
Re: 1.5 error handling Spring config buggy/not complete?
Posted by Fush <ri...@gmail.com>.
Claus Ibsen-2 wrote:
>
> Hi
>
> a)
> Ah that might not be clearly stated in the documentation.
>
> It's an *all* or *nothing* with transactions. If using transactions
> then it's the backing system (the transaction manger) responsibility
> to handle redelivery - not Camel. Camel in this case only supports
> delaying a fixed delay before the rollback is triggered.
>
> And as you use ActiveMQ as the backing system it is the ActiveMQ
> transaction manger that handles the redelivery. And it uses 5 or is it
> 6 redeliveries by default. So you should configure ActiveMQ how
> redelivery should be done.
> So, are you basically saying that I could remove the
> transactionErrorHandler bean from the route, and just set a
> redeliveryPolicy on the ActiveMQConnectionFactory instead?
Claus Ibsen-2 wrote:
>
> b)
> That said I turn to the onException
>
> Is TechnicalException and FunctionalException related as such one is
> inherited from the other?
> eg: FunctionalException extends TechnicalException ?
>
> Camel uses (by default) an instanceof test to verify which onException
> should handle the exception.
>
> You might have a use-case using transactions and onException that
> needs to be checked
> - You have onExceptions that also is meent to supoorts catch exception
> this exception and route it differently. And then you can have the
> handled=true to state it's okay, newer mind the exception I have
> handled it and the TX = OK.
> - But it can also be used as a if this exception is thrown then only
> retry 2 times instead of default 5 times etc.
> - etc.
> Both exceptions extend RuntimeException, and nothing else. So there's no
> other relationship between them.
Claus Ibsen-2 wrote:
>
> c)
> In any case it should really only call the myOwnErrorHandler only for
> the FunctionalException.
>
> I will check up on your spring XML and add it as a unit test in camel.
> I'm curious to see what you find out about this. Thanks!
--
View this message in context: http://www.nabble.com/1.5-error-handling-Spring-config-buggy-not-complete--tp20562554s22882p20576291.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: 1.5 error handling Spring config buggy/not complete?
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
a)
Ah that might not be clearly stated in the documentation.
It's an *all* or *nothing* with transactions. If using transactions
then it's the backing system (the transaction manger) responsibility
to handle redelivery - not Camel. Camel in this case only supports
delaying a fixed delay before the rollback is triggered.
And as you use ActiveMQ as the backing system it is the ActiveMQ
transaction manger that handles the redelivery. And it uses 5 or is it
6 redeliveries by default. So you should configure ActiveMQ how
redelivery should be done.
b)
That said I turn to the onException
Is TechnicalException and FunctionalException related as such one is
inherited from the other?
eg: FunctionalException extends TechnicalException ?
Camel uses (by default) an instanceof test to verify which onException
should handle the exception.
You might have a use-case using transactions and onException that
needs to be checked
- You have onExceptions that also is meent to supoorts catch exception
this exception and route it differently. And then you can have the
handled=true to state it's okay, newer mind the exception I have
handled it and the TX = OK.
- But it can also be used as a if this exception is thrown then only
retry 2 times instead of default 5 times etc.
- etc.
c)
In any case it should really only call the myOwnErrorHandler only for
the FunctionalException.
I will check up on your spring XML and add it as a unit test in camel.
/Claus Ibsen
Apache Camel Committer
Blog: http://davsclaus.blogspot.com/
On Tue, Nov 18, 2008 at 5:06 PM, Fush <ri...@gmail.com> wrote:
>
> Hi! Below is a snippet of my camel route/xml. As you can see, I'm trying to
> set up some transaction and error handling there. But I've ran into a couple
> of strange issues. Are these known? Can anyone here explain them?
>
> 1. Even if the exception thrown by myBean is a TechnicalException (ie. not a
> FunctionalException), the method on the myOwnErrorHandler bean is invoked.
> How can that happen?
> 2. Even if maximumRedeliveries is set to 0, for the two onException clauses,
> as well as in the redeliveryPolicyConfig, the message is redelivered 5 times
> (as default) when an exception occurs. Why are my settings of 0 not read?
> 3. Based on the above, can you spot any obvious errors in my configurations?
> Or should I assume the spring interpretation to be flawed?
>
> Here's the important part of my XML:
>
> <camelContext id="myRouting"
> xmlns="http://activemq.apache.org/camel/schema/spring">
> <route errorHandlerRef="transactionErrorHandler">
> <from uri="activemq:queue/myQueue/aQueue" />
> <!-- <policy ref="required"/>-->
> <choice>
> <when>
> <xpath>//type = 'myType'</xpath>
> <onException>
> <exception>org.my.exception.TechnicalException
> </exception>
> <redeliveryPolicy maximumRedeliveries="0" />
> <handled>
> <constant>true</constant>
> </handled>
> <!-- ANY SPECIFIC HANDLING HERE? -->
> </onException>
> <onException>
> <exception>org.my.exception.FunctionalException
> </exception>
> <redeliveryPolicy maximumRedeliveries="0" />
> <handled>
> <constant>true</constant>
> </handled>
> <to uri="bean:myOwnErrorHandler" />
> </onException>
> <unmarshal>
> <jaxb prettyPrint="true" contextPath="org.my.domain.message" />
> </unmarshal>
> <to uri="bean:myBean" />
> </when>
> </choice>
> </route>
> </camelContext>
>
> <bean id="jmsTransactionManager"
> class="org.springframework.jms.connection.JmsTransactionManager">
> <property name="connectionFactory" ref="jmsConnectionFactory" />
> </bean>
>
> <bean id="jmsConnectionFactory"
> class="org.apache.activemq.ActiveMQConnectionFactory">
> <property name="brokerURL" value="${org.my.activemq.url}"/>
> </bean>
>
> <bean id="jmsConfig"
> class="org.apache.camel.component.jms.JmsConfiguration">
> <property name="connectionFactory" ref="jmsConnectionFactory"/>
> <property name="transactionManager" ref="jmsTransactionManager"/>
> <property name="transacted" value="true"/>
> <property name="concurrentConsumers" value="1"/>
> </bean>
>
> <!-- camel policy we refer to in our route -->
> <bean id="required"
> class="org.apache.camel.spring.spi.SpringTransactionPolicy">
> <property name="template" ref="PROPAGATION_REQUIRED"/>
> </bean>
>
> <!-- the standard spring transaction template for required -->
> <bean id="PROPAGATION_REQUIRED"
> class="org.springframework.transaction.support.TransactionTemplate">
> <property name="transactionManager" ref="jmsTransactionManager"/>
> </bean>
>
> <!-- the transaction error handler we refer to from the route -->
> <bean id="transactionErrorHandler"
> class="org.apache.camel.spring.spi.TransactionErrorHandlerBuilder">
> <property name="transactionTemplate" ref="PROPAGATION_REQUIRED"/>
> <!-- here we refer to the configurations of the error handler -->
> <property name="delayPolicy" ref="redeliveryPolicyConfig"/>
> </bean>
>
> <!-- configuration of the transaction error handler -->
> <bean id="redeliveryPolicyConfig"
> class="org.apache.camel.processor.RedeliveryPolicy">
> <property name="delay" value="5000"/>
> <property name="maximumRedeliveries" value="0"/>
> </bean>
>
> <!-- ActiveMQ instance -->
> <bean id="activemq" class="org.apache.camel.component.jms.JmsComponent">
> <property name="configuration" ref="jmsConfig"/>
> </bean>
>
> <bean id="myOwnErrorHandler" class="org.my.beans.MyErrorHandler"/>
>
> <bean id="myBean" class="org.my.beans.MyBean"/>
> --
> View this message in context: http://www.nabble.com/1.5-error-handling-Spring-config-buggy-not-complete--tp20562554s22882p20562554.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>