camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raul Kripalani <r...@evosent.com>
Subject Re: [DISCUSS] Camel 3.0 - Core of the routing engine
Date Tue, 19 Feb 2013 09:51:56 GMT
I'll create a section in the evening with references to the associated
ideas.

How are we handling the prototyping of ideas? Collaborate on code, reviews,
(virtual) pair programming if we have a joint championship, etc. SVN is
inflexible, but GitHub has the social element we need.

Working on branches is the way to go, but "one idea = one branch" seems
naïve because ideas can easily be interrelated. Shall we form "clusters" of
related ideas and spawn off a branch for each cluster?

For example, this core re-engineering + the two ideas that Claus mentioned
can form an "idea cluster" (IC). The champions of the cluster can then
create a branch each if they wish, merging onto the IC branch, and
ultimately onto trunk if the implementation is approved by the community.

Regards,

*Raúl Kripalani*
Apache Camel Committer
Enterprise Architect, Program Manager, Open Source Integration specialist
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
http://blog.raulkr.net | twitter: @raulvk <http://twitter.com/raulvk>

On Tue, Feb 19, 2013 at 9:31 AM, Claus Ibsen <claus.ibsen@gmail.com> wrote:

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message