camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claus Ibsen (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CAMEL-6377) Optimize routing engine to reduce stack frames in use during routing and reduce callbacks
Date Sun, 26 May 2013 19:18:20 GMT

    [ https://issues.apache.org/jira/browse/CAMEL-6377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13661858#comment-13661858
] 

Claus Ibsen edited comment on CAMEL-6377 at 5/26/13 7:17 PM:
-------------------------------------------------------------

Things to do:

1. Naming the API is hard so the names is not set in stone. 
2. Passing state from before -> after, is the current approach fine?
3. All the current tasks are in the same parent class, this gives a full overview of the ones
we have. Should we put them in separate classes, and in a sub package?
4. Migrate JMX InstrumentationProcessor to a new task *(done for route, not possible yet for
each processor due we keep track of redeliveries as well)*
5. Migrate Tracer to a new task (a bit harder as it has some custom tracer factory and whatnot)
(the tracer is a bit ugly and should be ditched for Camel 3.0 and rewritten - or just rely
on backlog tracer) *(done by disabling tracer out of the box)*
6. Add more javadoc to the API if missing
7. Look at DefaultChannel and see if we should merge/migrate it with this new stuff.
8. And consider dropping the Channel name as it was a pseudo name, and EIP term for Channel
is better for external communication. Its only internal so end users is not affected.
9. All together its important to be backwards compatible and only do internal optimizations.
*(done)*
10. Optimized EIPs which would create wrapped UnitOfWorkProcessor, to use internal processor
task instead (*done*)
11. Migrate UnitOfWorkProcessor to CamelInternalProcessor, and remove these classes when no
longer needed (*done*)
12. for direct derived classes of AsyncDelegateProcessor, replace super.process(exchange,
callback) with processor.process(exchange, callback) as it avoids a useless method call (*done*)
13. on wrap when really needed in Policy / Transaction Definition (*done*)
14. optimize WrapProcessor to avoid using AsyncProcessorHelper when wrapped processor is not
asynchronous. (*done*)
15. optimize InstrumentationProcessor to detect if target processor is Async or Sync, and
call it directly and accordingly (this avoids the bridge) (*done*)
16. RedeliveryErrorHandler can avoid the processErrorHandler method and reduce one stack-frame
(*done*)
                
      was (Author: davsclaus):
    Things to do:

1. Naming the API is hard so the names is not set in stone. 
2. Passing state from before -> after, is the current approach fine?
3. All the current tasks are in the same parent class, this gives a full overview of the ones
we have. Should we put them in separate classes, and in a sub package?
4. Migrate JMX InstrumentationProcessor to a new task *(done for route, not possible yet for
each processor due we keep track of redeliveries as well)*
5. Migrate Tracer to a new task (a bit harder as it has some custom tracer factory and whatnot)
(the tracer is a bit ugly and should be ditched for Camel 3.0 and rewritten - or just rely
on backlog tracer) *(done by disabling tracer out of the box)*
6. Add more javadoc to the API if missing
7. Look at DefaultChannel and see if we should merge/migrate it with this new stuff.
8. And consider dropping the Channel name as it was a pseudo name, and EIP term for Channel
is better for external communication. Its only internal so end users is not affected.
9. All together its important to be backwards compatible and only do internal optimizations.
*(done)*
10. Optimized EIPs which would create wrapped UnitOfWorkProcessor, to use internal processor
task instead (*done*)
11. Migrate UnitOfWorkProcessor to CamelInternalProcessor, and remove these classes when no
longer needed (*done*)
12. for direct derived classes of AsyncDelegateProcessor, replace super.process(exchange,
callback) with processor.process(exchange, callback) as it avoids a useless method call (*done*)
13. on wrap when really needed in Policy / Transaction Definition (*done*)
14. optimize WrapProcessor to avoid using AsyncProcessorHelper when wrapped processor is not
asynchronous. (*done*)
15. optimize InstrumentationProcessor to detect if target processor is Async or Sync, and
call it directly and accordingly (this avoids the bridge) (*done*)
                  
> Optimize routing engine to reduce stack frames in use during routing and reduce callbacks
> -----------------------------------------------------------------------------------------
>
>                 Key: CAMEL-6377
>                 URL: https://issues.apache.org/jira/browse/CAMEL-6377
>             Project: Camel
>          Issue Type: Improvement
>          Components: camel-core
>    Affects Versions: 2.12.0
>            Reporter: Claus Ibsen
>            Assignee: Claus Ibsen
>             Fix For: 2.12.0
>
>
> We can optimize the Camel routing engine internally, and redue the need for wrapping
processors (those internally used for cross cutting functionality) where they would wrap each
other one by one; which then results in larger call stacks during routing.
> This also shows to end users when stacktraces is being logged etc, as they tend to be
a bit longer with many internal calls.
> Though the JVM optimizes this at runtime as it can inline the calls and whatnot. But
the stacktraces is still shown expanded.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message