camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Łukasz Dywicki <>
Subject Re: [DISCUSS] Camel 3.0 - Core of the routing engine
Date Tue, 19 Feb 2013 09:18:57 GMT
Raul you have huge
from me on this idea. 

Basically I was thinking about idea of "logical" modules for Camel 3.0 which could modify
routing chain, property configurations. Overall purpose is to get rid from core all magic
which was built around PropertiesComponent/TraceInterceptor and so on (don't know why it still
remains in core). I can't easily count how many instanceof statements we have in code.

The "module" thing came to me after using Jackson 2.0. An example module which enables Hibernate
integration can be found on github [1].


Kind regards,
Łukasz Dywicki
Twitter: ldywicki
Code-House -

Wiadomość napisana przez Christian Schneider <> w dniu 19 lut
2013, o godz. 08:20:

> +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:
>> 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
> Open Source Architect

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message