-----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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
