tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Follow-up: Possible false-postive with JreMemoryLeakPreventionListener and Tomcat's JDBC Pool and OracleTimeoutPollingThread
Date Wed, 05 Jun 2013 19:25:35 GMT
Hash: SHA256


On 5/17/13 5:36 AM, Mark Thomas wrote:
> On 17/05/2013 09:28, Michael-O wrote:
>> Hi folks,
>> there's now a follow-up on the issue [1]. Recap:
>> JreMemoryLeakPreventionListener reported that my webapp has
>> spawned OracleTimeoutPollingThread because I have set a
>> QueryTimeout in the JDBC Pool. Mark Thomas noted that this is
>> likely a bug in the driver. I have taken action and created a
>> service request with Oracle.
>> My personal analysis with VisualVM: The thread is spawned when
>> the first query is run. The thread keeps running when the webapp
>> is shut down or undeployed. Classes remain in memory. The JDBC
>> Pool does a simple Class.forName to load the driver, it neither
>> uses the DriverManager loading nor does it actively unload the
>> driver.
>> Oracle answer: They were able to reproduce the issue. The
>> technical analysis says:
>>> Hi Michael,
>>> I confirmned internally that this message from Tomcat can be
>>> ignored as there is no risk of any real leak from"
>>> OracleTimeoutPollingThread" thread. This thread is related to
>>> the JDBC driver which may be used by many apps simultaneously.
>>> Unloading the app does not unload the driver and should not and
>>> does not stop the thread.
>>> It seems to be the design behaviour.
>> So my questions would be: 1. Is that still not a false positive?
> No, that is not a false positive. The response from Oracle is
> wrong.
> There is nothing wrong with the driver creating the thread or the
> thread continuing after the web application has stopped. The
> problem is as follows:
> 1. When the JDBC driver creates the Thread, the Thread's context
> class loader (as returned by Thread.getContextClassLoader()) is set
> to the web application's class loader.
> 2. The correct behaviour at this point would be for the Driver to
> set the Thread's context class loader to the class loader that
> loaded the Driver class when the Thread is created.

I have recently observed with MySQL Connector/J that setting the
context ClassLoader to something else (in their case, null) is not

The problem is that the Thread's inherited, cached ProtectionDomain
chain is still linked-up with the WebappClassLoader and so switching
the contextClassLoader after thread-creation is not effective.

I think the only way to do it is by having the code that creates the
Thread make a contextClassLoader switch first, then create the Thread,
then switch back.

- -chris
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message