Wow. Nice improvement! On 2013-05-21 8:18 AM, "Claus Ibsen" <claus.ib...@gmail.com> wrote:
> Hi > > Okay so we got some good headway now. > > The sample use case on 2.11 has a stacktrace of about 40 lines (without > JMX). > And on trunk we are down to 17 now (without JMX) and +2 if JMX enabled. > > That is reducing the stack traces with by 3 fold in that given sample. > > > > On Mon, May 20, 2013 at 11:16 AM, Claus Ibsen <claus.ib...@gmail.com> > wrote: > > 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 <r...@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.ib...@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: cib...@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: cib...@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: cib...@redhat.com > Web: http://fusesource.com > Twitter: davsclaus > Blog: http://davsclaus.com > Author of Camel in Action: http://www.manning.com/ibsen >
