Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: error (nike.apache.org: local policy)
Message-ID: <51AF90AF.7020804@christopherschultz.net>
Date: Wed, 05 Jun 2013 15:25:35 -0400
From: Christopher Schultz <chris@christopherschultz.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8;
 rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Follow-up: Possible false-postive with
 JreMemoryLeakPreventionListener
 and Tomcat's JDBC Pool and OracleTimeoutPollingThread
References: 
 <trinity-bb070d69-1676-475a-af87-ee84b16a0148-1368779337252@3capp-gmx-bs52>
 <5195FA08.3090906@apache.org>
In-Reply-To: <5195FA08.3090906@apache.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Mark,

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
sufficient[1].

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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJRr5CuAAoJEBzwKT+lPKRY1OMQAJ6oQ4XjVzXq2imrG52HDix/
E1XNQYJGbjNIs+zS/JL8qjcKWDYGpykYobIZ5gNOCe5I+W419DSTOW9ff8/9djQF
Ui1IeLHe+NAUITxbqgrQjnxED0kkrBwrPDJLbr/+l4nW5ljKDkF9nv0EV+qDgx1L
cJ9ahr4FwsLo7NiHZ/4GjQ8T6gSyp3T2EpqCAE7gqDjYPyYT8i+GPLgxVHSFNzQy
8IYiqe7T7gPQwv8xrYQMks0L9HfnEdMrM4E+S1G5fIOP25VODR9BldMU8YvMKhLo
GXD+/dy0msl9IWoSKGoJMQmNQanh9uj74whmNQ3Ulf6Z7Jviz6OuHiukuNY7Awke
wL5U0J2ExJdFbHw8Jc67TvhmoIkmQ8N/nNI99RvZ5uVIHQ9dsg5hbRuc0V3E8ZJp
JSAVjqEUhHTC7E7DWwBqknAX4F1herCCeIBDJhh0HMJ+MYRWgSZTk/4ccEhEjkU8
1Yj7YFBaWucWGF4SPtac6YjItlWzGYNjVG5jKqkX1cYcIlfIJtuvPGy9nWDDl0Lv
pn1yWoirokwGssv5YEhUxeWTFnJoHD08ii17PJSkwBzL3l84ZVmIZbrodA+xWTNo
oTqVxjxSL0uOB7pI7TmGVWzm8GKLChoiHTwE88jt7KD1wLkRdwMDXdrCVlaZKAjq
pHTL8jry5JtriwOyQHhW
=sQg+
-----END PGP SIGNATURE-----

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