camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <>
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
<> 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

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

Claus Ibsen
Red Hat, Inc.
FuseSource is now part of Red Hat
Twitter: davsclaus
Author of Camel in Action:

View raw message