Hi It really depends on your business requirements. If you use JMS then the messages on the queue is ordered.
And if you use transaction then the consumer will rollback the message in case of an error, and redelivery the same message again. The message broker have option to control this, for example to move the failed message to a dead letter queue after X failed attempts. But there is nothing, AFAIR, on the JMS broker to say that on rollback the message should be moved to the tail of the queue. The message keeps its position, and thus the same message will be redelivered. However you can use concurrent consumers or group ids, to have other consumers process messages, while a given message on one consumer is kept being redelivered. Is ordering of the messages important to your business? If it doesn't matter then you got more options, as opposed to that the message must be processed in a given order. We have thought of adding persistent store to the Camel error handler, so you could have it instructed to use long lasting redelivery strategies. However that persistent storage may require your operations team to run and maintain it as well, if they want something like JDBC or JMS. We got a light weight alternative based on file which is called HawtDB which would be usable. Also there are a number of other NoSQL out there which could be interested to integrate and offer for persistent storage of Camel messages. On Sat, Nov 27, 2010 at 12:47 AM, Lorrin Nelson <[email protected]> wrote: > Great, thanks Claus! > > I've been thinking about your response. Although our volume is low and we can > probably get away with it, I appreciate your point that long retries create > the risk of big memory usage spikes as things pile up. Also I imagine it > might make it a little difficult to ascertain the current state of the system. > > Our use case is that we've got some messages going to systems with > unpredictable uptime. The long retries seemed like a simple way to ensure > that messages would be delivered eventually, even if it took a while for the > recipient to come online. > > What would be a good alternative? Sounds like there's nothing built into > Camel, but maybe I could create something easily enough: > > route#1: from(<some external producer> to(<local JMS queue>) > > route#2: transacted receipt from local JMS queue with simple delivery > attempt. If failed, either: > * update exchange to indicate failure and place back on JMS queue > * or decide message has been in system for too many days, move to dead > letter queue > > Is it safe to have route #2 sometimes place exchanges back on the same JMS > queue it's reading from? Would something else be better suited than JMS? > > Cheers > -Lorrin > > On Nov 24, 2010, at 7:37 AM, Claus Ibsen wrote: > >> Hi >> >> I created a ticket >> https://issues.apache.org/activemq/browse/CAMEL-3364 >> >> On Tue, Nov 23, 2010 at 11:55 AM, Claus Ibsen <[email protected]> wrote: >>> On Tue, Nov 23, 2010 at 2:42 AM, Lorrin Nelson >>> <[email protected]> wrote: >>>> The interaction between DefaultErrorHandler retries and >>>> DefaultShutdownStrategy seems broken. What I want: >>>> * long running infrequent retries. This seems like what >>>> DefaultErrorHandler is built for, thanks to it's exponential back-off >>>> feature >>>> * shutdown as soon as no retry is in-flight >>>> >>>> Instead, I get: >>>> * DefaultShutdownStrategy wants to wait until all future retries >>>> have been attempted! I've configured this to be days! But at least there's >>>> a timeout on the DefaultShutdownStrategy, so after a while of waiting >>>> around (while no retries are actually occurring), it proceeds. >>>> * DefaultShutdownStrategry logs "Timeout occurred. Now forcing the >>>> routes to be shutdown now.", but actually does nothing. The route keeps >>>> retrying and Tomcat still can't shutdown. >>>> >>>> Is this broken or have I misconfigured somehow? >>>> >>> >>> This is the intended behavior. Its generally not a good idea to have >>> redelivery lasting for days. The exchange then has to be stored in >>> memory until it has to do redelivery the next day. Its generally >>> better to try for a limited period, and then fail if still a problem. >>> >>> We could introduce some option to instruct the error handler to stop >>> attempt redeliveries if a shutdown has been commenced and then >>> indicate those exchanges failed by setting an exception on that. >>> >>> Fell free to create a JIRA for such an enhancement. >>> >>> >>>> -Lorrin >>> >>> >>> >>> -- >>> Claus Ibsen >>> ----------------- >>> FuseSource >>> Email: [email protected] >>> 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: [email protected] >> 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: [email protected] Web: http://fusesource.com Twitter: davsclaus Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/
