Details
-
Improvement
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
2.18.0
-
None
-
Moderate
Description
Camel leaks ThreadContextClassLoader instances at least in the following place:
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.