Thanks Claus.
Based on your comments I've created an alternative solution that uses
ActiveMQ 5.4's new delay feature:
https://github.com/tarka/Camel-Async-Test/tree/amq-delay-header
On a related note, is there a method of injecting headers in the
Spring XML route? Being able to do so would mean this solution could
be implemented entirely via configuration.
Cheers,
Steve
On 14 February 2011 19:16, Claus Ibsen <claus.ib...@gmail.com> wrote:
> Hi
>
> Its best to use the JMS Broker redelivery feature if possible.
> It has a persistent store for the messages, so they wont be lost in
> case of a crash.
>
> Also the JMS consumer doesn't support the async routing engine in InOnly mode
> http://camel.apache.org/asynchronous-routing-engine.html
>
> Which you need in your example. There is a ticket to improve this.
> https://issues.apache.org/jira/browse/CAMEL-3632
>
>
> On Mon, Feb 14, 2011 at 12:36 AM, Steve Smith <tarkast...@gmail.com> wrote:
>> Hi,
>>
>> All the documentation I've read (on the site and the book) implies
>> that if I enable asyncDelayedRedelivery on a queue's error handler the
>> queue should continue to deliver messages while there are retries
>> pending. However I cannot get Camel to produce this behaviour.
>>
>> To test this I've produced a small proof-of-concept app:
>>
>> https://github.com/tarka/Camel-Async-Test
>>
>> What it does:
>>
>> * Starts an embedded ActiveMQ broker, backed by a memory-only DB
>> * Creates two Camel JMS endpoints: 'inputq' and 'expiredMessages'
>> * There is a quartz job that injects 15 messages into the inputq, 1
>> second apart
>> * Expired messages routes to a simple logging bean
>> * 'inputq' is routed to a logging bean that throw errors a certain points:
>> ** After 5 messages it throws a PermanentFailureException
>> ** After 10 messages it throws a TemporaryFailureException
>> * The error handler is configured as follows:
>> ** PermanentFailureExceptions are immediately sent to the expired queue
>> ** TemporaryFailureExceptions are retried with the following parameters:
>> *** 3 retries
>> *** 10 second delay between retries
>> *** Asynchronous retries
>>
>> What I expect to see:
>>
>> * After the 10th message the remaining 5 messages are delivered and
>> logged immediately
>>
>> What I actually see:
>>
>> * The 5 messages are queued up, and only flush out after the 3 retries
>> of the 10th message
>>
>> The only explanation of this that I can see is that the JMS queues are
>> transacted, but I see no warning or errors regarding this so it's not
>> clear. Is this behavior expected? Am I missing something?
>>
>> Thanks,
>> Steve
>>
>
>
>
> --
> Claus Ibsen
> -----------------
> FuseSource
> Email: cib...@fusesource.com
> Web: http://fusesource.com
> Twitter: davsclaus
> Blog: http://davsclaus.blogspot.com/
> Author of Camel in Action: http://www.manning.com/ibsen/
>
