]
Markus Dlugi commented on WFLY-9742:
------------------------------------
Alright, thanks for the quick response. That's what I thought as well, I just
wasn't sure that there is no code which relies on the initial TCCL of the JBoss
Threads.
I could provide a PR for this if you want? Although it's just one line of code, so it
might be easier for you to do it yourself.
ClassLoader leak in JBoss Threads caused by MDBs
------------------------------------------------
Key: WFLY-9742
URL:
https://issues.jboss.org/browse/WFLY-9742
Project: WildFly
Issue Type: Bug
Affects Versions: 11.0.0.Final
Reporter: Markus Dlugi
Assignee: David Lloyd
Attachments: default-threads-tccl.png, jboss-threads-tccl-example.zip
There is a classloader leak in JBoss Threads which is most noticable when deploying MDBs.
When a new MDB is created and a new thread for the MDB is started in the JCA thread pool
("default-threads - x"), the thread will be created using the context
classloader of the MDB's deployment unit. This is because
[
MessageDrivenComponent.activate()|https://github.com/wildfly/wildfly/blob...]
sets the context classloader of the ServerService thread in order to create the MDB, and
this classloader will then also be used by the child thread.
In the default configuration, the threads in the default thread pool will not be
terminated and therefore the thread will keep the reference to the classloader even when
the deployment unit is undeployed. This in turn can lead to "OutOfMemoryError:
Metaspace" after a couple of redeployments.
As a workaround, we changed
[
JBossThreadFactory.createThread()|https://github.com/jbossas/jboss-thread...]
to set the context classloader to null after a new thread has been created. While this
fixes the issue for us, I am not sure whether this is a good solution for all consumers of
the thread factory, or if this should be fixed in the JCA subsystem instead. That's
also the reason why I opened this issue against the WildFly project instead of JBoss
Threads.