There is a lot of information here. Responses in-line.
On 24/04/2025 21:51, Simon Arame wrote:
<snip/>
Not sure I am interpreting the doc correctly, does this mean that the
concerned classes of the xercesImpl jar in <context>/WEB-INF/lib will be
ignored when there exists the equivalent in the bootstrap class loader
and/or the parent one if any ?
The default search order is:
- JRE
- WEB-INF/classes
- WEB-INF/lib
- $CATALINA_BASE/lib
The first class found with a matching name will be loaded.
<snip/>
1) GC Root from one of our class that has a static method that calls
SSLContext.setDefault() with an ssl context declared inside that static
method as parameter.
2) GC Root from a sun.awt.AppContext. We are not using AppContext directly
so I blocked there.
Does that finding of 2 ParallelWebappClassLoader was the right thing to
find ?
That seems reasonable at this point.
Moreover, I've found that there is one of the existing
org.apache.jasper.servlet.JasperLoader that contains the compiled JSP class
that is faulty, could that be related somehow?
Probably not.
I've changed the SSLContext.setDefault call from one of our class so it's
not dangling anymore
Great. It isn't surprising that there are multiple memory leaks. As you
fix some of them, others may appear.
Are you using org.apache.catalina.core.JreMemoryLeakPreventionListener ?
It is enabled by default and automatically fixes a bunch of known issues
with JREs and memory leaks. I ask as sun.awt.AppContext is one of the
leaks it can protect against but you have to enable it specifically with
appContextProtection="true"
and run the steps one more time, stopping all contexts
this time except tomcat's manager and opening the HPROF dump found:
1) XMLGregorianCalendarImpl in classes of
org.apache.catalina.loader.ParallelWebappClassLoader [Held by JVM]
2) XMLGregorianCalendarImpl from constant pool of
org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl which is the
datatypeFactory of com.sun.xml.bind.DatatypeConverterImpl which is the
theConverter of javax.xml.bind.DatatypeConverter which itself is a GC Root.
That is the leak. You have an instance of web application provided class
set as a static field in a JVM provided class. And there is no public
API provided by the JVM to enable you to clear that field.
Could I for instance add a Class.forName(javax.xml.bind.DatatypeConverter)
in my JSP or perhaps try to explicitly load that class differently?
At this point, I do not know what to do next!
A few options for you to try/consider
1.
If you run on a newer version of Java (11, 17, 21, etc), the JRE no
longer provides the javax.xml.bind package so that might resolve the
issue provided that the libraries packaged the web application do
include those classes. If not, you'll need to add the JAXB API JAR (and
possibly others).
If you try this option, I'd suggest using Java 11 since using later
versions may create other issues due to deprecations and removals.
2.
Move (don't copy) the Xerces JARs from WEB-INF/lib to $CATALINA_BASE/lib
- you'll need to do this for all of your web applications.
3.
Write a ServletContextListener that uses reflection to clear
javax.xml.bind.DatatypeConverter.theConverter on web application stop.
HTH,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
