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 cschneider111@gmail.com
 designates 74.125.83.50 as permitted sender)
Sender: Christian Schneider <cschneider111@gmail.com>
Message-ID: <512327A8.6040703@die-schneider.net>
Date: Tue, 19 Feb 2013 08:20:08 +0100
From: Christian Schneider <chris@die-schneider.net>
User-Agent: Mozilla/5.0 (X11; Linux i686;
 rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: dev@camel.apache.org
Subject: Re: [DISCUSS] Camel 3.0 - Core of the routing engine
References: <-5191488065940407854@unknownmsgid>
In-Reply-To: <-5191488065940407854@unknownmsgid>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

+1

I think one of the main things camel is missing is a routing engine.
Like you wrote, currently each processor calls the next. Aspects like
asynchronous behaviour, transaction and security are also
implemented as processors.

I think what we need is a runtime model of a camel route that represents
the route without aspects. The aspects should then be executed
by the routing engine without blowing up this model.

This change is pretty severe though. I am not sure if we can refactor
the camel core and keep it even somewhat compatible.
I also fear that once we start these changes there is no way back and we
might risk having an instable branch for a long time. So we have
to reduce this risk in some way.

Christian

On 19.02.2013 01:21, Raul Kripalani wrote:
> 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�l.
>


-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com