You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@camel.apache.org by "Claus Ibsen (Jira)" <ji...@apache.org> on 2020/10/12 05:39:00 UTC

[jira] [Assigned] (CAMEL-15671) Performance overhead of bean post processor when using camel spring

     [ https://issues.apache.org/jira/browse/CAMEL-15671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Claus Ibsen reassigned CAMEL-15671:
-----------------------------------

    Assignee: Claus Ibsen

> Performance overhead of bean post processor when using camel spring
> -------------------------------------------------------------------
>
>                 Key: CAMEL-15671
>                 URL: https://issues.apache.org/jira/browse/CAMEL-15671
>             Project: Camel
>          Issue Type: Improvement
>          Components: camel-spring
>    Affects Versions: 2.25.0
>            Reporter: Taras Tielkes
>            Assignee: Claus Ibsen
>            Priority: Major
>         Attachments: image-2020-10-10-11-37-02-339.png
>
>
> We are using the \{{http://camel.apache.org/schema/spring}} namespace to configure a Camel context from spring.
> It seems that {{CamelNamespaceHandler.CamelContextBeanDefinitionParser#doParse}} unconditionally registers a {{CamelBeanPostProcessor}} into the underlying Spring {{ApplicationContext}}: there is no guard or configuration option to prevent the execution of {{CamelNamespaceHandler#injectBeanPostProcessor}}.
> This is unfortunate, since we are _not_ using any of the Camel annotations in the beans present in the Spring application context of our application. At the same time, {{CamelBeanPostProcessor}} introduces dramatic runtime performance overhead.
> Specifically, any bean initialized and configured by the Spring application context will be inspected by the camel bena post processor for presence of Camel annotations. In our use-case, Spring {{@Configurable}} annotated entities are used, which can have bean creation rates of tens of thousands per second. Without the {{CamelBeanPostProcessor}} present, the performance impact of this is negligible. With the {{CamelBeanPostProcessor}} present, this introduces significant bottlenecks.
> See below for the relevant parts of the Camel annotation scanning code dominating this bottleneck (from a JFR recording).
> The use of the Spring Camel namespace seems to be conflated with the unconditional injection of the {{CamelBeanPostProcessor}}, with no configuration or strategy specialization option to separate these.
> For users using the namespace, but not using the Camel annotations, it would be very useful to have control over this aspect of Camel/Spring integration.
> !image-2020-10-10-11-37-02-339.png!
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)