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<https://forums.oracle.com/ords/apexds/user/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<mailto:j.l.ThreadGroup@c02fa828>, contextClassLoader : org.apache.catalina.loader.ParallelWebappClassLoader@c02fb4c8<https://forums.oracle.com/ords/apexds/user/c02fb4c8>, inheritedAccessControlContext : java.security.AccessControlContext@c492d448<mailto: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_<https://java.jiderhamn.se/2012/01/01/classloader-leaks-ii-find-and-work-around-unwanted-references/#cleanup>. (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
