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 raul@evosent.com designates
 209.85.210.182 as permitted sender)
From: Raul Kripalani <raul@evosent.com>
Mime-Version: 1.0 (1.0)
Date: Tue, 19 Feb 2013 00:21:03 +0000
Message-ID: <-5191488065940407854@unknownmsgid>
Subject: [DISCUSS] Camel 3.0 - Core of the routing engine
To: "dev@camel.apache.org" <dev@camel.apache.org>
Content-Type: multipart/alternative; boundary=f46d0402aeef3f187104d608d15d

--f46d0402aeef3f187104d608d15d
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello team,

We use a recursive model in our routing engine to chain processors with one
another to process exchanges.

This results in lengthy stacktraces and increased memory usage due to local
variable retention for longer than strictly needed, IMHO. This recent
question on Stack Overflow is a typical (short!) stacktrace:
http://stackoverflow.com/questions/14734983/camel-ftp-intermittent-issue.
Debugging
it can be daunting for users.

Moreover many infrastructural Processors are woven implicitly along the
processor chain. Maybe this logic should belong elsewhere (the routing core
itself?).

Now that the Camel routing model is consolidated, can we start thinking
about moving towards an iterative routing approach? I feel the recursive
approach worked wonders when Camel was still a baby and the architecture
was heavily evolving: basically any processor, at any point, could do
anything to the exchange. And everything was a processor. Flexible and
versatile!

But now that the concepts are well rooted, I feel we need to formally
define "the routing process", rather than leaving it all up to processors
to be assembled in the right order.

I realize my proposal may sound somewhat abstract at this point, but before
going to further length, I want to gauge if my concern is shared.

What do you think?

Ra=FAl.

--f46d0402aeef3f187104d608d15d--