[ 
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/28/13 9:39 AM:
-------------------------------------------------------------

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? *(done)* 
(yes this works well)
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. *(done)* (now DefaultChannel extends CamelInternalProcessor)
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. *(for camel 3.0)*
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. (*only partially possible*)
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*)
17. When calling a Processor using process then we should optimize that for 
sync vs async and be able to drop 1 frame by avoiding the bridge when in sync 
mode.
18. fix the remaining processors not implementing AsyncProcessor to avoid 
wrapping (SetBody, Transform, Aggregate, Marshall ...)
                
      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? *(done)* 
(yes this works well)
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. *(done)* (now DefaultChannel extends CamelInternalProcessor)
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. *(for camel 3.0)*
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. (*only partially possible*)
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*)
17. When calling a Processor using process then we should optimize that for 
sync vs async and be able to drop 1 frame by avoiding the bridge when in sync 
mode.
                  
> 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

Reply via email to