Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Thu, 7 Jul 2011 17:53:16 +0000 (UTC)
From: "Kathey Marsden (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: 
 <1262314770.8263.1310061196994.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <970557658.4824.1309978336933.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (DERBY-5316) Unload old JDBC drivers when done
 with them in the upgrade tests
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DERBY-5316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13061460#comment-13061460 ] 

Kathey Marsden commented on DERBY-5316:
---------------------------------------

That make sense. It is good to know that we are protected from class loader leaks moving forward with DERBY-2905.  I keep forgetting with the upgrade tests we haven't solved the time travel problem. 

  Perhaps the approach you mentioned in the email will work for the old versions. That just to have it here in the Jira was:
"One possible solution may be to create a helper class with a method that
unloads the embedded driver and somehow wire this class into the class
loader in which the old version is running. The helper class could be
used from the test tear-down. Then we should be able to trick
DriverManager into unloading the driver. I think..."

I wonder if it is possible to write a test to verify not only that the driver is deregistered (which I think was already done in DERBY-2905), but verify that class loaders get garbage collected and classes unloaded to prevent  other issues from creeping in.  Getting the upgrade tests to run within the default JVM parameters with the Sun JDK would be a good indicator but it would be nice to have a more targeted functional test.  I am just not sure how we would test that directly.


> Unload old JDBC drivers when done with them in the upgrade tests
> ----------------------------------------------------------------
>
>                 Key: DERBY-5316
>                 URL: https://issues.apache.org/jira/browse/DERBY-5316
>             Project: Derby
>          Issue Type: Improvement
>          Components: Test
>            Reporter: Knut Anders Hatlen
>
> Discussed in this thread on derby-dev: http://mail-archives.apache.org/mod_mbox/db-derby-dev/201107.mbox/%3C4E146309.3000906@gmail.com%3E
> After we're done testing an old version in the upgrade tests, its classes are still loaded in the JVM because the old driver is referenced in DriverManager. We should find a way to unload the old drivers so that the memory usage of the upgrade tests is reduced. Now we typically need to run with -XX:MaxPermSize=200M or similar options to work around this issue.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira