[
https://issues.apache.org/jira/browse/DERBY-5316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13061543#comment-13061543
]
Kristian Waagan commented on DERBY-5316:
----------------------------------------
The unstable and probably somewhat error-prone path would be to enable tracing
of class loading/unloading and parse the output. This requires us to kick off a
JVM process, and we have to deal with different options to enable the tracing,
output formats etc. I would think such a test shouldn't be included in
suites.All, since it may be sensitive to the test machine environment (i.e. VM
vendor and version).
Here's an example from running the upgrade tests with versions 10.7.1.1 and
10.8.1.2 (I did run GC explicitly before the JVM exited to be sure):
$ grep "EmbeddedDriver" output.txt
[Loaded org.apache.derby.jdbc.EmbeddedDriver from
file:release-jars/10.7.1.1/derby.jar]
[Loaded org.apache.derby.jdbc.EmbeddedDriver from file:trunk-netbeans/classes/]
[Loaded org.apache.derby.jdbc.EmbeddedDriver from
file:release-jars/10.8.1.2/derby.jar]
[Unloading class org.apache.derby.jdbc.EmbeddedDriver]
Note that the "origin" of the class is not included in the unloading-message.
I'm not sure if one would have to rely on counting of the events only, or if we
can conclude based on our knowledge of the test (i.e. when/how classes are
loaded/unloaded) and trace order. I expect that the filtering and parsing could
be done in Java as a JUnit test.
I have not experimented further.
> 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/%[email protected]%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
