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 2019/08/06 09:03:00 UTC

[jira] [Resolved] (CAMEL-10456) Camel leaks TCCL

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

Claus Ibsen resolved CAMEL-10456.
---------------------------------
    Resolution: Fixed

> Camel leaks TCCL
> ----------------
>
>                 Key: CAMEL-10456
>                 URL: https://issues.apache.org/jira/browse/CAMEL-10456
>             Project: Camel
>          Issue Type: Improvement
>          Components: camel-core
>    Affects Versions: 2.18.0
>            Reporter: Christoph Läubrich
>            Assignee: Claus Ibsen
>            Priority: Major
>             Fix For: 3.0.0, 3.0.0.M5
>
>
> Camel leaks ThreadContextClassLoader instances at least in the following place:
> camel-core: https://github.com/apache/camel/blob/4f9448d83cc21a348f92cca961907b0f72d9db79/camel-core/src/main/java/org/apache/camel/util/ObjectHelper.java#L1913
> As mentioned in the JavaDoc of Thread.getContextClassLoader() returning "null indicating the system class loader (or, failing that, the bootstrap class loader)", se same applies to Thread.setContextClassLoader(...)
> The code only reset the TCCL if the returned value from Thread.currentThread().getContextClassLoader() was != null. So if in a thread without a TCCL set (and thus returning null) these methods set a new CCL but later do not reset these to the original null value.
> This leads to Threads (e.g. when taking reused from a pool) having a classloader that will never gets reset and thus can't be garbage collected or even lead to strange behaviour because if other code that uses the TCCL-mechanism can try to load classes or resources from this loader later on.
> I found that https://github.com/apache/camel/blob/master/components/camel-jms/src/main/java/org/apache/camel/component/jms/JmsProducer.java#L85 uses a similar pattern, only resetting the TCCL if the *new* TCCL != null so maybe the code in ObjectHelper was meant to check for classloader != null instead of tccl !=null
> The fix should also include making sure this pattern is not used in other camel-components or even to use the ObjectHelper Method consistently, currently it seems may components implement their owh TCCL-handling.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)