camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <claus.ib...@gmail.com>
Subject Re: [DISCUSS] Camel 3.0 - Core of the routing engine
Date Tue, 19 Feb 2013 09:31:49 GMT
On Tue, Feb 19, 2013 at 8:20 AM, Christian Schneider
<chris@die-schneider.net> wrote:
> +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.
>


Its been on the Camel 3.0 roadmap for a long time

Though its heading caption may have been chosen a better wording than
- More flexible routes at runtime
http://camel.apache.org/camel-30-ideas.html

We had it as target for a long time, but as you said it safter to work
on this in a major release than on the 2.x architecture.
And hence why its not been done yet.

And in term of the model, then we have missing pieces about the
inteceptors/onExceptions and whatnot. This is also on the roadmap for
Camel 3.0
- Add OnException, Interceptor, etc. to JAXB model for a CamelContextDefinition


> 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
>



-- 
Claus Ibsen
-----------------
Red Hat, Inc.
FuseSource is now part of Red Hat
Email: cibsen@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen

Mime
View raw message