Camel's redelivery is immediate and doesn't go all the way back to the start of the route. The feature I'm hopefully adding today is the auto-suspending routes. The route itself will go to "sleep" for a bit to allow the problem to be fixed and not needlessly overflow the purgatory/dlc queues. We're trying to avoid dlc replays if we can. We would rather the system auto-heal. Now if the message that goes to purgatory is truly "poison" then it will indeed end up in the dlc queue, but that's where it belongs anyway. On Jun 8, 2012 7:47 AM, "gramanero" <graman...@gmail.com> wrote:
> So in your example, what is the difference between the Purgatory count and > using the Redelivery capabilities built into ActiveMQ and Camel policies? > Maybe I'm missing something, but it seems like the logic wrapped around the > Purgatory concept is just keeping track of how many times a message has > been > delivered and caused an exception to happen. This could happen if the "to" > endpoint is unavailable (i.e. a restful service) and until the service does > become available the count will go up until the message ends up in the DLQ. > > Like I said, maybe I'm just missing something here. > > -- > View this message in context: > http://camel.465427.n5.nabble.com/Transacted-vs-DeadLetterQueue-tp5713992p5714188.html > Sent from the Camel - Users mailing list archive at Nabble.com. >
