Hey Claus,
It's on my plate for this weekend.
Regards,
Raúl.
On Tue, May 28, 2013 at 12:18 PM, Claus Ibsen wrote:
> Possible 2 + 3 implemented.
>
>
> Raul did you by any chance had a chance to take a look also?
>
> What remains is gnodets suggest which has been listed as task 18.
> And then th
Hi
Have been working with the API while implementing all these
optimizations, I went for renaming Task -> Advice.
As its really an before + after advice we perform in the CamelInternalProcessor.
At this time I think the optimization is done. There is a potential
optimization in the SendProcessor
Possible 2 + 3 implemented.
Raul did you by any chance had a chance to take a look also?
What remains is gnodets suggest which has been listed as task 18.
And then the naming of the new API and possible adding a bit more javadoc etc.
On Tue, May 28, 2013 at 10:26 AM, Claus Ibsen wrote:
> Hi
On Tue, May 28, 2013 at 11:02 AM, Guillaume Nodet wrote:
> 2013/5/28 Claus Ibsen
>
>> Hi
>>
>> So after a week we got good progress on this one.
>> We have been able to reduce the stack-frames with a factor of 2 - 3 times.
>>
>> The sample we have been using for benchmark is down from 40 to 16.
>
2013/5/28 Claus Ibsen
> Hi
>
> So after a week we got good progress on this one.
> We have been able to reduce the stack-frames with a factor of 2 - 3 times.
>
> The sample we have been using for benchmark is down from 40 to 16.
> And there is room for 1, 2 or 3 more to be shaved off.
>
>
> Possi
Hi
So after a week we got good progress on this one.
We have been able to reduce the stack-frames with a factor of 2 - 3 times.
The sample we have been using for benchmark is down from 40 to 16.
And there is room for 1, 2 or 3 more to be shaved off.
Possible #1)
The JMX InstrumentationProcessor
Yes, exactly. Completely agree with this approach.
I'm amazed with the amount of stack frame bloat you've been able to remove
already! Great work!
I'm planning to contribute too. Will sync up with you on IRC.
Regards,
*Raúl Kripalani*
Enterprise Architect, Open Source Integration specialist, Pr
Cool. This change makes Camel more green :)
--
Willem Jiang
Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://www.fusesource.com | http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/)
(English)
http://jnn.iteye.com (http://jnn.java
Wow. Nice improvement!
On 2013-05-21 8:18 AM, "Claus Ibsen" 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
Awesome work Claus ! This will make camel much easier to debug imho.
2013/5/20 Claus Ibsen
> 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 m
I like it!
Sent from a mobile device
Am 21.05.2013 14:18 schrieb "Claus Ibsen" :
> 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
Am 21.05.13 14:17 schrieb "Claus Ibsen" unter :
>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 f
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 A
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 e
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
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
16 matches
Mail list logo
