On Thu, Feb 17, 2011 at 1:12 AM, Steve Smith <tarkast...@gmail.com> wrote: > 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. >
There is a setHeader in the XML DSL. If you have a good IDE then it should be able to code complete and assist when you edit the Camel XML files and popup with possible tags you can use. > 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/ >> > -- 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/
