[
https://issues.apache.org/jira/browse/CAMEL-24105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-24105.
---------------------------------
Resolution: Fixed
> camel-bean: @RoutingSlip/@RecipientList/@DynamicRouter processors are added
> as CamelContext services on every MethodInfo creation and never removed
> ---------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-24105
> URL: https://issues.apache.org/jira/browse/CAMEL-24105
> Project: Camel
> Issue Type: Bug
> Components: camel-bean
> Affects Versions: 4.21.0
> Reporter: Federico Mariani
> Assignee: Claus Ibsen
> Priority: Minor
> Fix For: 4.22.0
>
>
> The {{MethodInfo}} constructor registers annotation-driven EIP processors as
> CamelContext services:
> {code:java}
> if (routingSlipAnnotation != null) {
> routingSlip = ...createRoutingSlip(camelContext, routingSlipAnnotation);
> camelContext.addService(routingSlip); // never removed
> }
> {code}
> (same pattern for {{@DynamicRouter}} and {{@RecipientList}}).
> {{MethodInfo}} instances are created during {{BeanInfo}} introspection, and
> {{BeanInfo}} is cached in an LRU soft cache in {{BeanComponent}} (default
> size 1000). Whenever a {{BeanInfo}} for a class with such annotations is
> evicted and later re-introspected (cache pressure, many bean types, OGNL on
> ephemeral types, prototype-scope usage), a *new* processor is created and
> added to the context's service list — while the old one is never removed.
> Over long uptimes the context service list (and the associated started
> services) grows without bound.
> Suggested direction: tie the lifecycle of these processors to the
> {{BeanInfo}}/{{MethodInfo}} that owns them (remove the service when the owner
> is discarded), or deduplicate/reuse per (class, method, annotation) instead
> of per-{{MethodInfo}} instance.
> No test attached — reproducing requires forcing LRU eviction of the BeanInfo
> cache; the leak is evident from the add-without-remove pattern in
> {{MethodInfo.java}} (constructor) combined with the cache eviction in
> {{BeanComponent}}.
> _This issue was found by an AI-assisted code review. Reported by Claude Code
> on behalf of [~fmariani] (GitHub: Croway)._
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
