Re: Tomcat / Oracle JDBC OracleTimeoutPollingThread memory leak?

[Mark Thomas]

On 13/02/2023 19:12, Ragosta, Vincent wrote:




Is the above GC root, an example of the above condition?


Yes.


If so, can this be mitigated using the JreMemoryLeakPreventionListener, as 
illustrated in the Tomcat documentation, here -- 
https://tomcat.apache.org/tomcat-9.0-doc/config/listeners.html#JreMemoryLeakPreventionListener_Examples?


Yes.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Tomcat / Oracle JDBC OracleTimeoutPollingThread memory leak?

[Ragosta, Vincent]

Our Tomcat instance is configured to create a heap dump on out of memory 
conditions, and we often see a large amount of memory allocated to 
OracleTimeoutPollingThread. For example, here is once such instance:

465,922Kb (57.4%) Object tree for GC root(s) Java Static 
oracle.jdbc.driver.OracleTimeoutThreadPerVM.watchdog Leak candidate(s) found
Root object 
oracle.jdbc.driver.OracleTimeoutPollingThread@c492d2c0oracle.jdbc.driver.OracleTimeoutPollingThread(name
 : "OracleTimeoutPollingThread", priority : 10, threadQ : null, eetop : 
392972288, single_step : false, daemon : true, stillborn : false, target : 
null, group : j.l.ThreadGroup@c02fa828, 
contextClassLoader : 
org.apache.catalina.loader.ParallelWebappClassLoader@c02fb4c8,
 inheritedAccessControlContext : 
java.security.AccessControlContext@c492d448,
 threadLocals : null, inheritableThreadLocals : 
j.l.ThreadLocal$ThreadLocalMap(size: 2), stackSize : 0, nativeParkEventPointer 
: 0, tid : 119, threadStatus : 225, parkBlocker : null, blocker : null, 
blockerLock : Object@c492d660, uncaughtExceptionHandler : null, 
threadLocalRandomSeed : 0, threadLocalRandomProbe : 0, 
threadLocalRandomSecondarySeed : 0, knownTimeouts : 
oracle.jdbc.driver.OracleTimeoutThreadPerVM[](size: 32), count : 20, 
sleepMillis : 1000)

  1.  oracle.jdbc.driver.OracleTimeoutPollingThread ↘465,922Kb (57.4%), self 
136b (< 0.1%), 1 object(s)

I came across the following note:

Oracle JDBC driver, at least in some versions (such as ojdbc6), have a timeout 
detection thread, _oracle.jdbc.driver.OracleTimeoutPollingThread_, that 
according to reports has as its context classloader the classloader of the web 
application from which the first JDBC connection is requested, even if the 
driver itself resides on the server level. It seem this can be prevented by 
loading the class _oracle.jdbc.driver.OracleTimeoutThreadPerVM_ using the 
system classloader before any JDBC connections are opened, which can be 
achieved in _contextInitialized()_ of our 
_ServletContextListener_.
 (Thanks to Hal Deadman for the report!)

Ref: https://java.jiderhamn.se/category/classloader-leaks/

Is the above GC root, an example of the above condition?

We are using the following:

Oracle JDBC driver version 18.3.0.0.0

Tomcat 9.0.60.



If so, can this be mitigated using the JreMemoryLeakPreventionListener, as 
illustrated in the Tomcat documentation, here -- 
https://tomcat.apache.org/tomcat-9.0-doc/config/listeners.html#JreMemoryLeakPreventionListener_Examples?



Thank you,

Vincent