Hi The continued effort to optimize and trim the camel-core, then we are currently working on reducing object allocations. One part is the new flag to turn on exchange pooling (for recycling objects).
As part of routing messages by Camel then some details are stored by EIPs in the exchange properties, which is a map. The exchange properties can also be mixed with user data, so we have both together. So part of the optimizations is to separate this more, and store EiP state in "another way" that avoids object allocations and also does not mix up with user data. The JIRA is https://issues.apache.org/jira/browse/CAMEL-16326 The APIs on Exchange has been made aware of this, and if you do a getProperty(Exchange.EXCEPTION_CAUGHT) Then it works as today, but internally Camel knows that this key is reserved and performs an optimized lookup. The only effect is that getProperties() that returns a Map would not include those internal objects anymore, as it's intended to only return the user data properties, if the Camel end user has stored some data via setProperty("foo", ...) We may introduce a getProperties(boolean) where bool=true can return both internal + user However the progress of all these internal optimizations is showing great results. The routing engine has close to zero object allocations (a few complex EIPs like splitter, multicast, aggregator, does have some allocations, but we will look at this later). But at the end of the day, there will be object allocations when using Camel - all the user data (body, headers) that the components consume, or when producing. But then its not core Camel but the 3rd party components that cause this. This little example https://github.com/apache/camel-performance-tests/tree/master/profiling/timer-log ... went from allocation 2.5 mio objects to < 1000 when running for 2 minutes. -- Claus Ibsen ----------------- http://davsclaus.com @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
