-----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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJRnPPXAAoJEBzwKT+lPKRYLV8QAMIlybE7cMnT2XQTbmi9bB5+
RZqS+VHTCf6q36senH0KP5DF1b6d1XMcJEfkpGAOUsA7jye50NFbUf5HICOKqX2D
PSOt2GlDISHQvTyG3U2sBBZyxmtfHW9y13t+397qhC2X806WhbJGPWyWID9vCqX0
EcVF02jwTq6aWpI/aKasxuwS3BDpm7EUMloBX7XdHUYO8lR562rA68KWxGZO5CqD
x9Jho7wtUgoj2RlIB4/7mQQKO1k14upS9OFgqVbkLYRA2RLhT5eOHZTBT4jeIOYJ
gcNnF2f3hEx6rXeNaEdapn46wv1h4dVUNy4mvPi1THb0qb82NEsPYNIadV7CRDAT
eIjzLcjruab5FKlMMq8wRppXh7/+Y21Bd4f3xaPB2b9rmiuv0a4ixnpWGg4QH/3C
NZpKM1F+Lv4jkRaF45Je+Pqna3d/WTgN5kMwwVmC0q0f1Dab1nR0FmGBayRGat+/
qHodLD8bWZ2EVHBvmFXr3BHa4HAsNFSx6Wi630EOHuzFyNHUbkLP2MZxJiufM3+h
9uSDyDuoqWY16EauwHsnkouRAA8O56NlgJ8EALyO/+KV7mOFdjrT/O2VTYWIyVrf
sY3Kn+1UtLXEGf42p9K9fjdG/sGMD4PgJPryokg7UkyoxzP2mkWzOL4Rd1YtWzDD
0RraqDL/r9LszWrPilmN
=QT5q
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
