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: [HEADS UP] - Optimzing routing engine to reduce stack frames in use during routing
Date Mon, 20 May 2013 09:16:26 GMT
Hi

I added some tasks as comments on
https://issues.apache.org/jira/browse/CAMEL-6377#comment-13661858

The goal of CAMEL-6377 is to do *internal* optimiztion changes only
with the goal of minimazing the stack-frames in use, as well reduce
the long stacktraces our end users see. And also for the end users who
go down the path of debugging the Camel routing, then there is less
"callback hell".

As Raul said we have ideas sketched for Camel 3.0, where we can do
bigger changes, and as well do some API changes (if it makes
value/sense) etc. And the ideas that Raul refers to is much bigger and
takes a lot longer to implement. And possible some prototype is
needed. And also care has to be taken as we have DSL in Scala / Groovy
/ Kotlin etc. that may be affected. And also a large user base on 2.x
API that relies on this being stable etc.

However as in CAMEL-6377 with fairly little effort (half a friday +
half a day on weekend + half toda) + the effort for the remainder
tasks (eg the comment on the JIRA) we could get this implemented
fairly soon.

Its IMHO important to keep the scope on the goals of "reducing
stack-frames, less long stacktraces, and easier debugging). All the
stuff about iterative routing engine etc, is also what is captured on
the Camel 3.0 ideas page, and also sketched in more details by Raul
with his idea of "decision" being returned from the processor(s). But
that is IMHO not the current scope of CAMEL-6377. The scope is to be
internal optimizations on the current 2.x architecture.

If people wanna help with CAMEL-6377, then check the JIRA ticket and
the list of bulleted tasks.

The code changes is about to be committed later this afternoon. Just
running one extra fully sanity unit tests of the entire code base, to
ensure no regressions or other gremlins introduced. Including all the
OSGi tests which you need to run specially.




On Sat, May 18, 2013 at 5:39 PM, Raul Kripalani <raul@evosent.com> wrote:
> Hi Claus,
>
> It's great that you're finding time for this. The need to lighten
> stacktraces was already brought up within the Camel 3.0 context [1]. In
> fact, there's also an entry in the roadmap page [2] which proposes moving
> away from the recursive model into an iterative routing engine.
>
> It's clear that the next step in that area is a prototype. I hope I can
> start working on that soon, even though the whole Camel 3.0 conversation
> seems to have cooled down at present.
>
> Anyway, do you have a concrete work plan or list of processors you'd are
> targeting with https://issues.apache.org/jira/browse/CAMEL-6377?
>
> If so, could you create a few individual JIRA tasks? I'd happily take on
> some of the simplification/rationalisation work!
>
> Regards,
>
> [1]
> http://camel.465427.n5.nabble.com/DISCUSS-Camel-3-0-Core-of-the-routing-engine-td5727754.html
> [2] http://camel.apache.org/camel-30-ideas.html
>
> *Raúl Kripalani*
> Enterprise Architect, Open Source Integration specialist, Program
> Manager | Apache
> Camel Committer
> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> http://blog.raulkr.net | twitter: @raulvk
>
> On Sat, May 18, 2013 at 3:38 PM, Claus Ibsen <claus.ibsen@gmail.com> wrote:
>
>> Hi
>>
>> Just to tell about the work I am currently doing
>> https://issues.apache.org/jira/browse/CAMEL-6377
>>
>> We have room to optimize the routing engine in Camel to make it more
>> friendlier to end users in terms of
>> - reduced stacktraces
>> - faster and easier to debug the code if you single step through all
>> the routing engine logic
>> - potential optimization to skip over functionality that is turned off
>> (eg such as tracer etc)
>> - potential optimization to add new cross cutting functionality at
>> runtime (though not currently the primary goal)
>> - potential to skip using RedeliveryErrorHandler/DefaultErrorHandler
>> if end user have not configured to use any kind of redelivery (the
>> reason is that logic in this guy is excessive and is harder for people
>> to debug)
>> - reduce wrapping internal processors when not needed
>>
>>
>> There is a sample route in the ticket where a stacktrace is forced
>> being thrown. And the difference is 40 vs 28 lines in the stacktrace.
>> And there is room for further optimization.
>>
>> The work is aimed at being non invasive on the current architecture
>> and also backwards compatible. So far I have noticed a problem with
>> the old behavior I have logged as:
>> https://issues.apache.org/jira/browse/CAMEL-6378
>>
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> www.camelone.org: The open source integration conference.
>>
>> 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
>>



-- 
Claus Ibsen
-----------------
www.camelone.org: The open source integration conference.

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