You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@camel.apache.org by "Federico Mariani (Jira)" <ji...@apache.org> on 2026/07/15 14:07:00 UTC

[jira] [Created] (CAMEL-24105) camel-bean: @RoutingSlip/@RecipientList/@DynamicRouter processors are added as CamelContext services on every MethodInfo creation and never removed

Federico Mariani created CAMEL-24105:
----------------------------------------

             Summary: 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


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)