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 <[EMAIL PROTECTED]>
> 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 <[EMAIL PROTECTED]> 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.
