On Tue, May 28, 2013 at 11:02 AM, Guillaume Nodet <[email protected]> wrote: > 2013/5/28 Claus Ibsen <[email protected]> > >> 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. >> > > I don't think we should go too far and remove any feature. > >> >> >> 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. > > > What I had in mind is rather the opposite, i.e. make sure we don't use any > Processor which does not implement AsyncProcessor, not calling the > processor synchronously. > I think it's easier to do and has the same result, i.e. not having to call > ProcessorToAsyncProcessorBridge. >
Yeah this would be possible for all the EIPs and processors we offer out of the box in Camel. But for end users who implement a custom Processor, eg just do implements Processor, then we would need to use the bridge, or enhance the logic in the routing engine, to not use the bridge and call the sync method directly. Though yeah if all the EIPs etc in Camel is AsyncProcessor then we are all good. Its only the custom end user Processor that may be sync only. > >> >> >> >> >> >> >> >> >> >> >> >> -- >> Claus Ibsen >> ----------------- >> www.camelone.org: The open source integration conference. >> >> Red Hat, Inc. >> FuseSource is now part of Red Hat >> Email: [email protected] >> Web: http://fusesource.com >> Twitter: davsclaus >> Blog: http://davsclaus.com >> Author of Camel in Action: http://www.manning.com/ibsen >> -- Claus Ibsen ----------------- www.camelone.org: The open source integration conference. Red Hat, Inc. FuseSource is now part of Red Hat Email: [email protected] Web: http://fusesource.com Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen
