[ 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 8:12 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. 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*) > 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