camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claus Ibsen (Commented) (JIRA)" <>
Subject [jira] [Commented] (CAMEL-4575) Persistant Dead Letter Channel to avoid memory consumption between retries
Date Sun, 23 Oct 2011 08:20:32 GMT


Claus Ibsen commented on CAMEL-4575:

There is some logic in DefaultExchangeHolder to serialize/unserialize a Camel Exchange. We
use that in the persistent aggregator. So we should use that logic here as well.

Long term the trick would be to survice server crashes, and support recovery when Camel comes
back online, as the persistent store needs to keep state if the exchange has been redelivered
or not. And how many redelivery attempts has already been made. 
The aggregator supports this. 

This logic should IMHO not be implemented in a patch release, and thus only applicable for
> Persistant Dead Letter Channel to avoid memory consumption between retries
> --------------------------------------------------------------------------
>                 Key: CAMEL-4575
>                 URL:
>             Project: Camel
>          Issue Type: New Feature
>          Components: camel-core
>            Reporter: Jean-Baptiste Onofré
>             Fix For: 2.8.3, 2.9.0
> When using a DeadLetterChannel, the messages are stored in memory between the retries
(redeliveries). They are flushed from the memory only when we get the maximumRedeliveries
> It means that we can have an important memory consumption, because the messages are memory
resident for a long time when:
> - if we have an important maximumRedeliveries, especially if we have -1
> - if we have an important redeliveryDelay
> I propose to create a PersistentDeadLetterChannel, working like the DeadLetterChannel,
but, between redeliveries, the messages are flushed to a persistent store (filesystem, JMQ
queue, JDBC, ...).

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message