Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Received-SPF: pass (athena.apache.org: domain of claus.ibsen@gmail.com
 designates 209.85.210.45 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:from:date:message-id:subject:to:content-type;
        b=Xa6HaOcxtWGHRNumk7H0VDkH+/ojfbfnApBAQLBo9iB5s+Ko51NEoN6I94x07YiDNo
         zrZ9AgJPxCyGz7vuLr2ZEpA9/Yu9C2d1rjRE/RH0WhaUerO+IxpZ8kqNu5kunx50nHrd
         F9oNN+DxOc83+D1IAC0Tegn4RSfFYnBhs7yzg=
MIME-Version: 1.0
From: Claus Ibsen <claus.ibsen@gmail.com>
Date: Sun, 19 Jun 2011 11:11:09 +0200
Message-ID: <BANLkTikc8pb=+J4hnMDvgOxm5_vOLx-4Wg@mail.gmail.com>
Subject: [DISCUSS] - Error handler and redelivery with a Processor - Time to
 take action
To: dev <dev@camel.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

Hi

I am working on
https://issues.apache.org/jira/browse/CAMEL-4117

This ticket is about an issue in Camel error handler and doing
redelivery when using a Processor in the route (eg
.process(myProcessor)).
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
success.

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: https://issues.apache.org/jira/browse/CAMEL-1817
And wrote down some ideas for improving this:
http://camel.apache.org/camel-2x-speed-optimizations.html
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
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/