Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Message-ID: <5188CAFE.50401@apache.org>
Date: Tue, 07 May 2013 10:35:58 +0100
From: Mark Thomas <markt@apache.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Aw: Re: Possible false-postive with
 JreMemoryLeakPreventionListener
 and Tomcat's JDBC Pool
References: 
 <trinity-227e694d-8105-4d4a-8acc-cf3c64f55dad-1367914613061@3capp-gmx-bs14>,
 <5188BCB5.1080400@apache.org>
 <trinity-9ee3bd29-6d64-49f0-b39f-de98fb224541-1367918725941@3capp-gmx-bs60>
In-Reply-To: 
 <trinity-9ee3bd29-6d64-49f0-b39f-de98fb224541-1367918725941@3capp-gmx-bs60>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 07/05/2013 10:25, Michael-O wrote:
> 
>> Von: "Mark Thomas" <markt@apache.org> On 07/05/2013 09:16,
>> Michael-O wrote:
>>> Hi folks,
>>> 
>>> I recently enabled a QueryTimeoutInterceptor with queryTimeout of
>>> 60 seconds in a JDBC Pool data source (7.0.37). When the app was
>>> shut down, Tomcat said: "The web application [/...] appears to
>>> have started a thread named [OracleTimeoutPollingThread] but has
>>> failed to stop it..."
>>> 
>>> We are using Oracle 11.2g with 11.2.0.3 JDBC drivers. I have
>>> figured out that this thread is spawned by the driver itself.
>>> According to this Stackoverflow answer [1] this is a long-living
>>> thread, same says the JDBC FAQ [2] of Oracle.
>>> 
>>> The thread seems to work like Pool's PoolCleaner thread. A few
>>> month a ago I reported the same issue with the PoolCleaner thread
>>> and Filip fixed the class loader orders.
>>> 
>>> Can this be a false-positive by the memory leak detector since
>>> this thread lives only once in the entire VM?
>> 
>> No. It is a memory leak and either or bug in your application or in
>> the JDBC driver.
>> 
>> Where is the Oracle JDBC driver? CATALINA_[BASE|HOME]/lib or
>> WEB-INF/lib
> 
> The driver is in the $CATALINA_HOME/lib only where $CATALINA_BASE !=
> $CATALINA_HOME. This was done for a single webapp for testing
> purposes.
> 
> Does this make a difference?

The important thing is that it isn't in WEB-INF/lib.

> How do you know that this is not a false-positive?

Experience, a lot of research into memory leaks and I wrote Tomcat's
memory leak detection code.

> If you really know for sure, I can open a service
> request with Oracle Support.

Good luck with that.

The problem is that when the driver creates the thread it does so when
the current class loader is the web application class loader. That means
that the Thread will be created with a context class loader set to the
web application class loader. That will trigger a memory leak when the
web application is stopped because a reference is retained to the web
application's class loader.

What the driver should do is, after it creates the thread, set the
thread's context class loader to the class loader that loaded the driver.

What you are seeing is a variation of the leak described on page 15 of [1].

Mark

[1]
http://people.apache.org/~markt/presentations/2010-11-04-Memory-Leaks-60mins.pdf

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