Mark,
On 8/23/21 04:05, Mark Thomas wrote:
On 23/08/2021 08:10, Thomas Hoffmann (Speed4Trade GmbH) wrote:
<snip/>
Is there anything, the application can prevent this?
Yes. Call Thread.setContextClassLoader(ClassLoader) before calling the
code that creates those threads, passing the common class loader.
Afterwards, reset the TCCL back to the web application class loader.
Should Tomcat maybe skip the warning if the thread is demonized?
No. The threads have the web app class loader as their TCCL so you have
a potential memory leak. The warning is correct.
Or maybe these threads should be ignored when checking for orphaned
threads?
No, for the same reason.
It was tested with Tomcat 9.0.52, Windows 10, Coretto-JDK 11.0.12_7.
You might want to consider raising a bug against the JDK. It could be
argued that those threads should be created with a specific class loader
to avoid memory leaks in container environments.
+1
I looked at the JREMemoryLeakPreventionListener and it looks like it
only initializes static stuff in the class using Class.forName(className().
I wonder if it would be helpful to also try to call a zero-arg
constructor for the class if one exists. In this case, it would allow
Tomcat (using this listener) to initialize this class (via
instantiation) so the application doesn't have to mess-around with the TCCL.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
