You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by dougly <dm...@gmail.com> on 2008/12/05 20:52:54 UTC

Redilivery Strategy

Hi,
I have the following route:

from("jms:topic:example").process(new MyProcessor());

If during the exchange processing exceptions are thrown, I would like to be
able to retry that exchange again.

I am thinking about using the Transactional client described in EIP but also
I find out that Dead Letter Channel has the redelivery mechanism to achieve
the same thing.

So experts, in this case should I just use the Dead Letter channel
redelivery to shift the exchange back to the JMS topic for another try?

Thanks

Doug
-- 
View this message in context: http://www.nabble.com/Redilivery-Strategy-tp20861316s22882p20861316.html
Sent from the Camel - Users mailing list archive at Nabble.com.


Re: Redilivery Strategy

Posted by Claus Ibsen <cl...@gmail.com>.
Hi

There is a difference in *transaction client EIP* and the *dead letter
channel* EIP

Transactional
Uses true transactions using commit/rollback so the operations is all
or nothing.
This is handled 100% *not* by Camel but by the backing external system
(the transaction manager).
Only some transports support transaftions such as: JMS, JDBC etc.

So if you want to rollback on the JMS topic then you need transactions
and to use the transaction manager from the JMS broker.


Dead Letter Channel
Does *not* use transactions but will retry the step in the routing
that failed. This is handled 100% by Camel.



/Claus Ibsen
Apache Camel Committer
Blog: http://davsclaus.blogspot.com/



On Fri, Dec 5, 2008 at 8:52 PM, dougly <dm...@gmail.com> wrote:
>
> Hi,
> I have the following route:
>
> from("jms:topic:example").process(new MyProcessor());
>
> If during the exchange processing exceptions are thrown, I would like to be
> able to retry that exchange again.
>
> I am thinking about using the Transactional client described in EIP but also
> I find out that Dead Letter Channel has the redelivery mechanism to achieve
> the same thing.
>
> So experts, in this case should I just use the Dead Letter channel
> redelivery to shift the exchange back to the JMS topic for another try?
>
> Thanks
>
> Doug
> --
> View this message in context: http://www.nabble.com/Redilivery-Strategy-tp20861316s22882p20861316.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>

Re: Redelivery Strategy

Posted by Claus Ibsen <cl...@gmail.com>.
Hi Doug

Great looks like you got the grip with Camel now.

Splitting the route is a great solution.
And actually it does make the routing easier to read ;)


/Claus Ibsen
Apache Camel Committer
Blog: http://davsclaus.blogspot.com/



On Sat, Dec 6, 2008 at 5:24 PM, dougly <dm...@gmail.com> wrote:
>
> Hi Claus,
> To work around this, I have redefined the following route:
>
> from("jms:topic:example").aggregator(...).to("Seda:start");
>
> from("seda:start").onException(....).process(...);
>
> So far it seems to works fine with the extra endpoint.
>
> Thanks for your help.
>
>
> Claus Ibsen-2 wrote:
>>
>> Hi Doug
>>
>> I have fixed it now in 1.5.1 and 2.0.
>>
>> However I do think the 1.5.1-SNAPSHOT is currently not published to a
>> maven repo. Willem wrote something about it.
>> I don't know the status of this, but I am sure we are gonna get it
>> sorted so the 1.x branch will have SNAPSHOTS published automatically
>>
>> /Claus Ibsen
>> Apache Camel Committer
>> Blog: http://davsclaus.blogspot.com/
>>
>>
>>
>> On Sat, Dec 6, 2008 at 10:50 AM, Claus Ibsen <cl...@gmail.com>
>> wrote:
>>> Hi Doug
>>>
>>> Ah you have spotted a bug. Basically the aggregate has a flaw if you
>>> don't add it in the start of the route, right after the from, so we
>>> added this exception to force end users to have it in the start. But
>>> the onException now injects itself in between as well, so its
>>> from.onexception.aggreagator. So onException fools the aggreagator.
>>>
>>> We have a ticket to fix the aggreagator so it can be defined anywhere.
>>> I think we need to convert the exception into a WARN logging for now.
>>> https://issues.apache.org/activemq/browse/CAMEL-1150
>>>
>>>
>>>
>>> /Claus Ibsen
>>> Apache Camel Committer
>>> Blog: http://davsclaus.blogspot.com/
>>>
>>>
>>>
>>> On Fri, Dec 5, 2008 at 10:20 PM, dougly <dm...@gmail.com> wrote:
>>>>
>>>> thanks for clarifying this.
>>>>
>>>> However when I try to use the dead letter channel redelivery method I
>>>> got
>>>> the
>>>>
>>>> "Aggregator must be the only output added to the route" logged! And the
>>>> configured routes do not start at all.
>>>>
>>>> Aggregator must be the only output added to the route:
>>>> Route[[From[jms:topic:example]] -> [Exception[[class
>>>> com.lyfam.TestException] -> [To[mock:error]]]]]
>>>>
>>>> Basically I like to redeliver the exchange if the SNIPPET 1 code throws
>>>> exception.
>>>>
>>>> Here is the layout of my route:
>>>>
>>>> public void configure() throws Exception {
>>>> errorHandler(deadLetterChannel("mock:error").maximumRedeliveries(2));
>>>>
>>>> onException(TestException.class)
>>>>                    .maximumRedeliveries(1)
>>>>                    .to("mock:error");
>>>>
>>>>
>>>> from("imap:localhost?username=test&password=test")
>>>>    .process(new MyProcessor())
>>>>    .to("jms:topic:example");
>>>>
>>>> from("jms:topic:memo")
>>>>    .aggregator(
>>>>                        new PredicateAggregationCollection(
>>>>                                header("testId"),
>>>>                                new AggregationStrategy()
>>>>                                {
>>>>                                    @Override
>>>>                                    public Exchange aggregate(Exchange
>>>> oldExchange, Exchange newExchange)
>>>>                                    {
>>>>                                        ......
>>>>                                        return newExchange;
>>>>                                    }
>>>>                                },
>>>>
>>>> header(Exchange.AGGREGATED_COUNT).isEqualTo(2)))
>>>>                .batchTimeout(500L)
>>>>                .process(new Processor(){
>>>>
>>>>                    // SNIPPET 1
>>>>                    @Override
>>>>                    public void process(Exchange exh) throws Exception
>>>>                    {
>>>>                        ......
>>>>                    }
>>>>                    // end SNIPPET 1
>>>>                });
>>>> }
>>>>
>>>> Thanks for helping
>>>>
>>>>
>>>> dougly wrote:
>>>>>
>>>>> Hi,
>>>>> I have the following route:
>>>>>
>>>>> from("jms:topic:example").process(new MyProcessor());
>>>>>
>>>>> If during the exchange processing exceptions are thrown, I would like
>>>>> to
>>>>> be able to retry that exchange again.
>>>>>
>>>>> I am thinking about using the Transactional client described in EIP but
>>>>> also I find out that Dead Letter Channel has the redelivery mechanism
>>>>> to
>>>>> achieve the same thing.
>>>>>
>>>>> So experts, in this case should I just use the Dead Letter channel
>>>>> redelivery to shift the exchange back to the JMS topic for another try?
>>>>>
>>>>> Thanks
>>>>>
>>>>> Doug
>>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/Redelivery-Strategy-tp20861316s22882p20862711.html
>>>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>>>
>>>>
>>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Redelivery-Strategy-tp20861316s22882p20871790.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>

Re: Redelivery Strategy

Posted by dougly <dm...@gmail.com>.
Hi Claus,
To work around this, I have redefined the following route:

from("jms:topic:example").aggregator(...).to("Seda:start");

from("seda:start").onException(....).process(...);

So far it seems to works fine with the extra endpoint.

Thanks for your help.


Claus Ibsen-2 wrote:
> 
> Hi Doug
> 
> I have fixed it now in 1.5.1 and 2.0.
> 
> However I do think the 1.5.1-SNAPSHOT is currently not published to a
> maven repo. Willem wrote something about it.
> I don't know the status of this, but I am sure we are gonna get it
> sorted so the 1.x branch will have SNAPSHOTS published automatically
> 
> /Claus Ibsen
> Apache Camel Committer
> Blog: http://davsclaus.blogspot.com/
> 
> 
> 
> On Sat, Dec 6, 2008 at 10:50 AM, Claus Ibsen <cl...@gmail.com>
> wrote:
>> Hi Doug
>>
>> Ah you have spotted a bug. Basically the aggregate has a flaw if you
>> don't add it in the start of the route, right after the from, so we
>> added this exception to force end users to have it in the start. But
>> the onException now injects itself in between as well, so its
>> from.onexception.aggreagator. So onException fools the aggreagator.
>>
>> We have a ticket to fix the aggreagator so it can be defined anywhere.
>> I think we need to convert the exception into a WARN logging for now.
>> https://issues.apache.org/activemq/browse/CAMEL-1150
>>
>>
>>
>> /Claus Ibsen
>> Apache Camel Committer
>> Blog: http://davsclaus.blogspot.com/
>>
>>
>>
>> On Fri, Dec 5, 2008 at 10:20 PM, dougly <dm...@gmail.com> wrote:
>>>
>>> thanks for clarifying this.
>>>
>>> However when I try to use the dead letter channel redelivery method I
>>> got
>>> the
>>>
>>> "Aggregator must be the only output added to the route" logged! And the
>>> configured routes do not start at all.
>>>
>>> Aggregator must be the only output added to the route:
>>> Route[[From[jms:topic:example]] -> [Exception[[class
>>> com.lyfam.TestException] -> [To[mock:error]]]]]
>>>
>>> Basically I like to redeliver the exchange if the SNIPPET 1 code throws
>>> exception.
>>>
>>> Here is the layout of my route:
>>>
>>> public void configure() throws Exception {
>>> errorHandler(deadLetterChannel("mock:error").maximumRedeliveries(2));
>>>
>>> onException(TestException.class)
>>>                    .maximumRedeliveries(1)
>>>                    .to("mock:error");
>>>
>>>
>>> from("imap:localhost?username=test&password=test")
>>>    .process(new MyProcessor())
>>>    .to("jms:topic:example");
>>>
>>> from("jms:topic:memo")
>>>    .aggregator(
>>>                        new PredicateAggregationCollection(
>>>                                header("testId"),
>>>                                new AggregationStrategy()
>>>                                {
>>>                                    @Override
>>>                                    public Exchange aggregate(Exchange
>>> oldExchange, Exchange newExchange)
>>>                                    {
>>>                                        ......
>>>                                        return newExchange;
>>>                                    }
>>>                                },
>>>
>>> header(Exchange.AGGREGATED_COUNT).isEqualTo(2)))
>>>                .batchTimeout(500L)
>>>                .process(new Processor(){
>>>
>>>                    // SNIPPET 1
>>>                    @Override
>>>                    public void process(Exchange exh) throws Exception
>>>                    {
>>>                        ......
>>>                    }
>>>                    // end SNIPPET 1
>>>                });
>>> }
>>>
>>> Thanks for helping
>>>
>>>
>>> dougly wrote:
>>>>
>>>> Hi,
>>>> I have the following route:
>>>>
>>>> from("jms:topic:example").process(new MyProcessor());
>>>>
>>>> If during the exchange processing exceptions are thrown, I would like
>>>> to
>>>> be able to retry that exchange again.
>>>>
>>>> I am thinking about using the Transactional client described in EIP but
>>>> also I find out that Dead Letter Channel has the redelivery mechanism
>>>> to
>>>> achieve the same thing.
>>>>
>>>> So experts, in this case should I just use the Dead Letter channel
>>>> redelivery to shift the exchange back to the JMS topic for another try?
>>>>
>>>> Thanks
>>>>
>>>> Doug
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Redelivery-Strategy-tp20861316s22882p20862711.html
>>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>>
>>>
>>
> 
> 

-- 
View this message in context: http://www.nabble.com/Redelivery-Strategy-tp20861316s22882p20871790.html
Sent from the Camel - Users mailing list archive at Nabble.com.


Re: Redelivery Strategy

Posted by Claus Ibsen <cl...@gmail.com>.
Hi Doug

I have fixed it now in 1.5.1 and 2.0.

However I do think the 1.5.1-SNAPSHOT is currently not published to a
maven repo. Willem wrote something about it.
I don't know the status of this, but I am sure we are gonna get it
sorted so the 1.x branch will have SNAPSHOTS published automatically

/Claus Ibsen
Apache Camel Committer
Blog: http://davsclaus.blogspot.com/



On Sat, Dec 6, 2008 at 10:50 AM, Claus Ibsen <cl...@gmail.com> wrote:
> Hi Doug
>
> Ah you have spotted a bug. Basically the aggregate has a flaw if you
> don't add it in the start of the route, right after the from, so we
> added this exception to force end users to have it in the start. But
> the onException now injects itself in between as well, so its
> from.onexception.aggreagator. So onException fools the aggreagator.
>
> We have a ticket to fix the aggreagator so it can be defined anywhere.
> I think we need to convert the exception into a WARN logging for now.
> https://issues.apache.org/activemq/browse/CAMEL-1150
>
>
>
> /Claus Ibsen
> Apache Camel Committer
> Blog: http://davsclaus.blogspot.com/
>
>
>
> On Fri, Dec 5, 2008 at 10:20 PM, dougly <dm...@gmail.com> wrote:
>>
>> thanks for clarifying this.
>>
>> However when I try to use the dead letter channel redelivery method I got
>> the
>>
>> "Aggregator must be the only output added to the route" logged! And the
>> configured routes do not start at all.
>>
>> Aggregator must be the only output added to the route:
>> Route[[From[jms:topic:example]] -> [Exception[[class
>> com.lyfam.TestException] -> [To[mock:error]]]]]
>>
>> Basically I like to redeliver the exchange if the SNIPPET 1 code throws
>> exception.
>>
>> Here is the layout of my route:
>>
>> public void configure() throws Exception {
>> errorHandler(deadLetterChannel("mock:error").maximumRedeliveries(2));
>>
>> onException(TestException.class)
>>                    .maximumRedeliveries(1)
>>                    .to("mock:error");
>>
>>
>> from("imap:localhost?username=test&password=test")
>>    .process(new MyProcessor())
>>    .to("jms:topic:example");
>>
>> from("jms:topic:memo")
>>    .aggregator(
>>                        new PredicateAggregationCollection(
>>                                header("testId"),
>>                                new AggregationStrategy()
>>                                {
>>                                    @Override
>>                                    public Exchange aggregate(Exchange
>> oldExchange, Exchange newExchange)
>>                                    {
>>                                        ......
>>                                        return newExchange;
>>                                    }
>>                                },
>>
>> header(Exchange.AGGREGATED_COUNT).isEqualTo(2)))
>>                .batchTimeout(500L)
>>                .process(new Processor(){
>>
>>                    // SNIPPET 1
>>                    @Override
>>                    public void process(Exchange exh) throws Exception
>>                    {
>>                        ......
>>                    }
>>                    // end SNIPPET 1
>>                });
>> }
>>
>> Thanks for helping
>>
>>
>> dougly wrote:
>>>
>>> Hi,
>>> I have the following route:
>>>
>>> from("jms:topic:example").process(new MyProcessor());
>>>
>>> If during the exchange processing exceptions are thrown, I would like to
>>> be able to retry that exchange again.
>>>
>>> I am thinking about using the Transactional client described in EIP but
>>> also I find out that Dead Letter Channel has the redelivery mechanism to
>>> achieve the same thing.
>>>
>>> So experts, in this case should I just use the Dead Letter channel
>>> redelivery to shift the exchange back to the JMS topic for another try?
>>>
>>> Thanks
>>>
>>> Doug
>>>
>>
>> --
>> View this message in context: http://www.nabble.com/Redelivery-Strategy-tp20861316s22882p20862711.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>
>>
>

Re: Redelivery Strategy

Posted by Claus Ibsen <cl...@gmail.com>.
Hi Doug

Ah you have spotted a bug. Basically the aggregate has a flaw if you
don't add it in the start of the route, right after the from, so we
added this exception to force end users to have it in the start. But
the onException now injects itself in between as well, so its
from.onexception.aggreagator. So onException fools the aggreagator.

We have a ticket to fix the aggreagator so it can be defined anywhere.
I think we need to convert the exception into a WARN logging for now.
https://issues.apache.org/activemq/browse/CAMEL-1150



/Claus Ibsen
Apache Camel Committer
Blog: http://davsclaus.blogspot.com/



On Fri, Dec 5, 2008 at 10:20 PM, dougly <dm...@gmail.com> wrote:
>
> thanks for clarifying this.
>
> However when I try to use the dead letter channel redelivery method I got
> the
>
> "Aggregator must be the only output added to the route" logged! And the
> configured routes do not start at all.
>
> Aggregator must be the only output added to the route:
> Route[[From[jms:topic:example]] -> [Exception[[class
> com.lyfam.TestException] -> [To[mock:error]]]]]
>
> Basically I like to redeliver the exchange if the SNIPPET 1 code throws
> exception.
>
> Here is the layout of my route:
>
> public void configure() throws Exception {
> errorHandler(deadLetterChannel("mock:error").maximumRedeliveries(2));
>
> onException(TestException.class)
>                    .maximumRedeliveries(1)
>                    .to("mock:error");
>
>
> from("imap:localhost?username=test&password=test")
>    .process(new MyProcessor())
>    .to("jms:topic:example");
>
> from("jms:topic:memo")
>    .aggregator(
>                        new PredicateAggregationCollection(
>                                header("testId"),
>                                new AggregationStrategy()
>                                {
>                                    @Override
>                                    public Exchange aggregate(Exchange
> oldExchange, Exchange newExchange)
>                                    {
>                                        ......
>                                        return newExchange;
>                                    }
>                                },
>
> header(Exchange.AGGREGATED_COUNT).isEqualTo(2)))
>                .batchTimeout(500L)
>                .process(new Processor(){
>
>                    // SNIPPET 1
>                    @Override
>                    public void process(Exchange exh) throws Exception
>                    {
>                        ......
>                    }
>                    // end SNIPPET 1
>                });
> }
>
> Thanks for helping
>
>
> dougly wrote:
>>
>> Hi,
>> I have the following route:
>>
>> from("jms:topic:example").process(new MyProcessor());
>>
>> If during the exchange processing exceptions are thrown, I would like to
>> be able to retry that exchange again.
>>
>> I am thinking about using the Transactional client described in EIP but
>> also I find out that Dead Letter Channel has the redelivery mechanism to
>> achieve the same thing.
>>
>> So experts, in this case should I just use the Dead Letter channel
>> redelivery to shift the exchange back to the JMS topic for another try?
>>
>> Thanks
>>
>> Doug
>>
>
> --
> View this message in context: http://www.nabble.com/Redelivery-Strategy-tp20861316s22882p20862711.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>

Re: Redelivery Strategy

Posted by dougly <dm...@gmail.com>.
thanks for clarifying this.

However when I try to use the dead letter channel redelivery method I got
the 

"Aggregator must be the only output added to the route" logged! And the
configured routes do not start at all.

Aggregator must be the only output added to the route:
Route[[From[jms:topic:example]] -> [Exception[[class
com.lyfam.TestException] -> [To[mock:error]]]]]

Basically I like to redeliver the exchange if the SNIPPET 1 code throws
exception.

Here is the layout of my route:

public void configure() throws Exception {
errorHandler(deadLetterChannel("mock:error").maximumRedeliveries(2));

onException(TestException.class)
                    .maximumRedeliveries(1)
                    .to("mock:error");


from("imap:localhost?username=test&password=test")
    .process(new MyProcessor())
    .to("jms:topic:example");

from("jms:topic:memo")
    .aggregator(
                        new PredicateAggregationCollection(
                                header("testId"),
                                new AggregationStrategy()
                                {
                                    @Override
                                    public Exchange aggregate(Exchange
oldExchange, Exchange newExchange)
                                    {
                                        ......
                                        return newExchange;
                                    }
                                },
                               
header(Exchange.AGGREGATED_COUNT).isEqualTo(2)))
                .batchTimeout(500L)
                .process(new Processor(){

                    // SNIPPET 1
                    @Override
                    public void process(Exchange exh) throws Exception
                    {
                        ......
                    }
                    // end SNIPPET 1
                });
}

Thanks for helping


dougly wrote:
> 
> Hi,
> I have the following route:
> 
> from("jms:topic:example").process(new MyProcessor());
> 
> If during the exchange processing exceptions are thrown, I would like to
> be able to retry that exchange again.
> 
> I am thinking about using the Transactional client described in EIP but
> also I find out that Dead Letter Channel has the redelivery mechanism to
> achieve the same thing.
> 
> So experts, in this case should I just use the Dead Letter channel
> redelivery to shift the exchange back to the JMS topic for another try?
> 
> Thanks
> 
> Doug
> 

-- 
View this message in context: http://www.nabble.com/Redelivery-Strategy-tp20861316s22882p20862711.html
Sent from the Camel - Users mailing list archive at Nabble.com.