Taras Tielkes created CAMEL-15671:
-------------------------------------
Summary: 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: Bug
Components: camel-spring
Affects Versions: 2.25.0
Reporter: Taras Tielkes
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)
