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 is harder to "reduce" as it wraps the processor in the route to be executed, eg - an EIP - a custom bean - a custom processor - etc. So it sits there and track utilization, how many calls, how long time, how many success / failures / redeliveries etc. And its this fine grained "redelivery" that is a challenge. If we want to keep having fine grained redelivery tracking and whatnot, then it has to sit just at the edge of the actual processor being invoked, eg in between the error handler and the processor. So when the error handler "kick in" and do a redelivery, we can keep track of that. Possible #2) Just noticed these two which can be optimized. This ought to be easy and doable. at org.apache.camel.processor.RedeliveryErrorHandler.processErrorHandler(RedeliveryErrorHandler.java:391) at org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:273) Possible #3) When calling a custom Processor that is only sync we could enhance logic at places to call the sync processor without using the ProcessorToAsyncProcessorBridge. This is also what gnodet have suggested. -- 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
