On May 22, 2013, at 11:35 AM, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Nick,
>
> On 5/22/13 10:18 AM, Nick Williams wrote:
>>
>> On May 22, 2013, at 9:09 AM, Christopher Schultz wrote:
>>
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>>
>>> Mark,
>>>
>>> On 5/21/13 2:38 PM, Mark Thomas wrote:
>>>> On 21/05/2013 19:01, Michael-O wrote:
>>>>> Mark,
>>>>>
>>>>> I did receive an answer to the issue, citing your findings.
>>>>> See verbatim copy below:
>>>>>
>>>>> Hi Michael,
>>>>>
>>>>> I received the following update from our developer:
>>>>>
>>>>> **********************************************************
>>>>> The theoretical problem is that the thread is holding the app
>>>>> class loader so it remains reachable and the app is never
>>>>> unloaded. So if the user loads and unloads the app, the app
>>>>> classes remain in memory. Subsequent loading and unloading of
>>>>> the app will not get pinned in memory as the thread is
>>>>> already running so the subsequent loading and unloading will
>>>>> not cause additional class loaders to be pinned. It is a
>>>>> fixed size memory leak. It does not grow.
>>>>>
>>>>> The thread suggests setting the context class loader to be
>>>>> the parent of the default context class loader. This may work
>>>>> in Tomcat but it's pretty random. I am researching the
>>>>> problem to determine what if anything the driver should do to
>>>>> work across all containers. A Tomcat specific fix is not
>>>>> acceptable.
>>>>
>>>> Almost but not quite. The correct fix is to set the context
>>>> class loader of the Thread to the class loader that loaded the
>>>> Driver
>>>
>>> +1
>>>
>>>> or, alternatively, the class loader that loaded the thread
>>>> class.
>>>
>>> Do you mean java.lang.Thread (primordial)? Or whatever subclass
>>> they are using? Maybe it would be more accurate to say "the
>>> ClassLoader of the runnable being run" which covers
>>> thread-subclasses or standard Runnables being run by a standard
>>> Thread.
>>
>> Or why not just java.sql.DriverManager.class.getClassLoader()?
>> Since drivers are always stored in the DriverManager regardless of
>> what class loader they're loaded in (hence why you shouldn't put
>> the driver in WEB-INF/lib), isn't the alway-correct solution to use
>> the class loader that loaded the DriverManager for this thread?
>
> I suspect that the DriverManager will always be loaded by the boot
> ClassLoader, since the default-dispatch for ClassLoaders is to chekc
> the parent first, then check "yourself". The DriverManager is at the
> top-level (well, there is primordial, but that doesn't really count)
> ClassLoader so you'll always get that.
>
> I don't think that will work because the boot ClassLoader won't be
> able to load the JDBC driver's classes, since they are in the
> container's ClassLoader. (boot ClassLoader should be set to
> CATLAINA_BASE/bin/*.jar while the container's ClassLoader will be set
> to CATALINA_BASE/lib/*.jar).
>
> Also remember that not all JDBC drivers are "registering" drivers:
> some were explicitly-written *not* to register themselves because of
> foolishness like this. When you are using a connection-pool, there's
> no reason to register the driver with the DriverManager because the
> pool itself acts kind of as the driver manager.
>
> For example MySQL's Connector/J com.mysql.jdbc.Driver class extends
> "NonRegisteringDriver" and adds only a static initializer that
> basically does this:
>
> static {
> DriverManager.register(new Driver());
> }
>
> So if I wanted to (and I probably should!), I could change my "driver"
> configuration from com.mysql.jdbc.Driver to
> com.mysql.jdbc.NonRegisteringDriver and avoid the DriverManager
> entirely. (And your suggestion above would not really be valid
> anymore, since the DriverManager is not involved).
>
> - -chris
Ahh. That makes sense.
And I will be changing my context.xml resource definitions now... :-)
Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
