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 2022/03/31 04:43:00 UTC

[jira] [Resolved] (CAMEL-17712) Memory leak in DefaultCamelContext reported by Tomcat 10

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

Claus Ibsen resolved CAMEL-17712.
---------------------------------
    Resolution: Won't Do

> Memory leak in DefaultCamelContext reported by Tomcat 10
> --------------------------------------------------------
>
>                 Key: CAMEL-17712
>                 URL: https://issues.apache.org/jira/browse/CAMEL-17712
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-core-engine
>    Affects Versions: 3.14.1
>         Environment: Apache Camel 3.14.1
> Tomcat 10
> Java 17
>            Reporter: Thomas Hoffmann
>            Assignee: Claus Ibsen
>            Priority: Minor
>             Fix For: 3.16.0, 3.14.2, 3.11.6
>
>
> Hello,
> we are using Camel inside a Tomcat application. The application also supports reloading of the context.
> Unfortunately, we are getting a memory leak report, e.g.
> {code:java}
> [Catalina-utility-1] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [ROOT] created a ThreadLocal with key of type [java.lang.ThreadLocal.SuppliedThreadLocal] (value [java.lang.ThreadLocal$SuppliedThreadLocal@588bee00]) and a value of type [org.apache.camel.impl.DefaultCamelContext.OptionHolder] (value [org.apache.camel.impl.DefaultCamelContext$OptionHolder@1d5c4495]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.{code}
>  
> Looking at the code, the problem is within the java class DefaultCamelContext
> [https://github.com/apache/camel/blob/main/core/camel-core-engine/src/main/java/org/apache/camel/impl/DefaultCamelContext.java]
> It contains a class variable which is always instantiated with:
> ThreadLocal<OptionHolder> OPTIONS = ThreadLocal.withInitial(OptionHolder::new);
> This ThreadLocal is never cleaned up by OPTIONS.remove(), This should be added to the shutdown() or stop() handler maybe(?)
> Some additional null checks would have to be implemented as well to make it safe.
>  
> Thanks,
> Thomas



--
This message was sent by Atlassian Jira
(v8.20.1#820001)