Christoph Läubrich created CAMEL-10456:
------------------------------------------
Summary: Camel leaks TCCL
Key: CAMEL-10456
URL: https://issues.apache.org/jira/browse/CAMEL-10456
Project: Camel
Issue Type: Bug
Components: camel-core
Reporter: Christoph Läubrich
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
(v6.3.4#6332)
