Hi We started with implementing this in the route consumers (eg from) where we have control of the lifecycle of. the exchange and what happens, so we can ensure they get released back to the pool
PollingConsumer are used more sparingly and only in the pollEnrich EIP and then from the ConsumerTemplate. The former as part of EIPs we can likely handle this as we can ensure to release the exchange after done routing. The latter with the template is responsible for the end user (in some of the APIs, eg those returning Exchange) to do this - eg like we demand with must call doneUoW (unit of work). So its a end user requirement. So there is potential here too. I created a ticket about this https://issues.apache.org/jira/browse/CAMEL-16260 On Thu, Feb 25, 2021 at 11:13 AM Zoran Regvart <zo...@regvart.com> wrote: > > Hi Claus, > would this change polling consumers in a way that the exchange from > the previous step is passed on to the polling consumer? I'm guessing > not, but just in case, I think that would be a welcome change. > Currently for polling consumers in poll enrich scenarios it's > difficult to pass data into the consumer other than through dynamic > endpoints and there is also the need for aggregation. So that might > lead to a lot of one-off endpoints in the poll enricher pool. > > zoran > > On Wed, Feb 24, 2021 at 5:31 PM Claus Ibsen <claus.ib...@gmail.com> wrote: > > > > Hi > > > > I am putting the final touches on > > https://issues.apache.org/jira/browse/CAMEL-16222 > > https://issues.apache.org/jira/browse/CAMEL-16213 > > > > Which is a large commit as it uses a new ExchangeFactory api > > that components with consumers now use when they create a Camel Exchange > > instance to contain the incoming message they are consuming and about > > to route in Camel. > > > > We need this factory so we have a way of controlling this behaviour - > > before each component could do this in their own way without a way for > > us to hook into that process. > > > > The default factory will now create a new Exchange instance. > > However you can enable "pooled" mode which will reuse exchange instances. > > > > The idea is to allow Camel to be lighter and reduce object allocations > > (reduce GC). > > For low traffic then the effect is of course minimal. But for high > > volume and streaming events > > then it has a positive effect. > > > > Another side effect is that it will also mean that the objects > > allocation by Camel during runtime will be reduced as it would only be > > a very minimal set of state information used during routing (such as > > an index in the chain of processors to know which one is the next > > etc). > > > > Another positive is that the exchange instance will be "warmed up" by > > having its internal Maps that we use for storing headers / exchange > > properties already at a capacity to hold the user data for the next > > message - eg when messages payload/headers are similar size/structure. > > > > So yet another optimization in the many lines of things we have been > > working on for Camel 3. > > > > I am currently preparing this work as a PR (it has 101 individual > > commits) so there are a few merge conflicts when rebasing from > > master). I would try to get this into a single commit and as a PR. > > > > During this work I identified some other points to optimize, so will > > work on then next. > > > > This introduces a change in the Consumer interface where there are > > methods to create and release Exchange's (via the factory) which > > component developers are recommended to use. You can keep using the > > old API and create the Exchange manually or via Endpoint. But the > > pooling is only possible by using the new API. All relevant Camel > > components out of the box have been updated. > > > > > > > > -- > > Claus Ibsen > > ----------------- > > http://davsclaus.com @davsclaus > > Camel in Action 2: https://www.manning.com/ibsen2 > > > > -- > Zoran Regvart -- Claus Ibsen ----------------- http://davsclaus.com @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
