camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claus Ibsen (JIRA)" <>
Subject [jira] [Updated] (CAMEL-10456) Camel leaks TCCL
Date Wed, 09 Nov 2016 10:41:58 GMT


Claus Ibsen updated CAMEL-10456:
    Fix Version/s: Future

> Camel leaks TCCL
> ----------------
>                 Key: CAMEL-10456
>                 URL:
>             Project: Camel
>          Issue Type: Improvement
>          Components: camel-core
>    Affects Versions: 2.18.0
>            Reporter: Christoph Läubrich
>             Fix For: Future
> Camel leaks ThreadContextClassLoader instances at least in the following place:
> camel-core:
> 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
> 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
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

View raw message