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/
>
