camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <>
Subject [DISCUSS] - Error handler and redelivery with a Processor - Time to take action
Date Sun, 19 Jun 2011 09:11:09 GMT

I am working on

This ticket is about an issue in Camel error handler and doing
redelivery when using a Processor in the route (eg
When Camel performs a redelivery it will redeliver the same Exchange
again, with whatever state was done in the pervious invocation.

So if the end user changes some state on the Exchange such as setting
an OUT message, a FAULT, or change the message body etc.
Those changes are kept and used for redeliveries.

This is not how that works, when you use eg a Bean, To etc in the
route as Camel will only update the Exchange if the operation was a

We have in the past looked into this when we were busy doing Camel 2.0
but hadn't the luxury and time to get this sorted back then.
We captured this in ticket:
And wrote down some ideas for improving this:
And as a bonus the changes should improve the memory footprint and
performance during routing.

Those ideas have been postponed to Camel 3.0, but since Camel 3.0 is
not around the corner. I suggest to move forward some of these ideas,
to correct CAMEL-4117 but also look into reducing the need for a
defensive copy of the Exchange in the Pipeline, as that logic is not
only needed
by the RedeliveryErrorHandler (CAMEL-1817).

Let me try to summarize
- CAMEL-4117: Shows a bug/issue with redelivery when using .processor,
the Exchange will carry over dirty content between redeliveries (this
is not expected by end users)
- CAMEL-1817: Moves the defensive copy from Pipeline to
RedeliveryErrorHandler (well it frankly belong in redelivery error
handler, as this is where we need it).
  And this also improves memory footprint and performance. We can
further optimize RedeliveryErrorHandler to only do defensive copy if
needed (eg redelivery is enabled)

So why now?
Well in Camel 2.8 we have fixed/improved some other issues with error
handling (eg what to do when a 2nd exception occurs while handling an
exception, such as when doing onException).
And there has been other slight fixes/improvements as well. So we may
as well further improve error handling in this release.

Camel 3.0 has not been started yet and even if we start today, its
most likely it would take 6+ months to get that work done. So I start
to fell its becoming a bit too later to wait with correcting this.
Especially if we can also in general reduce memory footprint and
improve performance a bit (notice the gain is due reduced memory usage
during routing).

Okay my ramblings is over. Let me dig into the code.

Any thoughts?

Claus Ibsen
Twitter: davsclaus, fusenews
Author of Camel in Action:

View raw message