On Tue, Feb 19, 2013 at 8:20 AM, Christian Schneider <ch...@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: cib...@redhat.com Web: http://fusesource.com Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen
