camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lorrin Nelson <>
Subject Re: DefaultShutdownStrategy can't shutdown DefaultErrorHandler's retries?
Date Fri, 26 Nov 2010 23:47:44 GMT
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,
	* 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?


On Nov 24, 2010, at 7:37 AM, Claus Ibsen wrote:

> Hi
> I created a ticket
> On Tue, Nov 23, 2010 at 11:55 AM, Claus Ibsen <> wrote:
>> On Tue, Nov 23, 2010 at 2:42 AM, Lorrin Nelson
>> <> 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:
>> Web:
>> Twitter: davsclaus
>> Blog:
>> Author of Camel in Action:
> -- 
> Claus Ibsen
> -----------------
> FuseSource
> Email:
> Web:
> Twitter: davsclaus
> Blog:
> Author of Camel in Action:

View raw message