[
https://issues.apache.org/jira/browse/DERBY-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John H. Embretsen updated DERBY-2480:
-------------------------------------
Attachment: d2480-junitTest_v1.stat
d2480-junitTest_v1.diff
Attaching a patch (d2480-junitTest_v1.diff) which adds a JUnit test class to
the ...functionTests.tests.memory package and a build file for that package.
The test class is named ConnectionHandlingJunit.java, and its functionality is
similar to that of the existing non-JUnit test class ConnectionHandling.java in
the same package, added for DERBY-444. I imagine that the older test may be
converted to JUnit at some point so that the two can be combined into one class
- I was not creative enough to come up with a better name for the new test
class.
The test uses java.sql.DriverManager to attempt to get a connection to a
database that does not exist. The test is set up to run 130 thousand attempts,
which should be more than enough to trigger this bug in JVMs with up to 64 MB
of max heap size (the default on many desktop machines/JVMs).
The test is set up to run in embedded mode only. The test can run in
client/server mode as well, but it has to be slightly modified and recompiled -
see implementation comments.
The test has not been added to any larger JUnit suite, because it a) takes a
while to run and b) eats JVM resources if the bug is present.
Run the test for example by doing:
java junit.textui.TestRunner
org.apache.derbyTesting.functionTests.tests.memory.ConnectionHandlingJunit
To observe test status (including memory "usage") while it is running, include
-Dderby.tests.debug=true when starting the TestRunner.
Without Jeff's latest patch memory usage increases dramatically and an
OutOfMemoryError is eventually thrown. With Jeff's patch, memory usage is very
low and stable. I've run the test on Sun's JVMs 1.4.2_02, 1.5.0_07 and
1.6.0_01, using sane jars.
The test does not always fail when an OutOfMemoryError is thrown - I think this
may be because the JVM is running out of resources and crashes before it gets
that far. In any case, an alarm message should be printed when such an error
occurs.
Please review/commit.
> DriverManager.getConnection leaks memory when connecting to a non-existent
> database
> -----------------------------------------------------------------------------------
>
> Key: DERBY-2480
> URL: https://issues.apache.org/jira/browse/DERBY-2480
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.1.3.1,
> 10.2.1.6, 10.2.2.0, 10.3.0.0
> Environment: Windows Vista, JDK 1.4.2_13
> Solaris 10, Sun JDK 1.4.2, 1.5.0 & 1.6.0
> Red Hat Enterprise Linux 4 (2.6.9-34.ELsmp_64), Sun JDK 1.5.0 & 1.6.0
> Reporter: Jeff Clary
> Assigned To: John H. Embretsen
> Priority: Minor
> Attachments: d2480-junitTest_v1.diff, d2480-junitTest_v1.stat,
> DERBY-2480-1.diff, derbyall_report.txt, heap-server-Xmx32m.png,
> Patch_DERBY-1947_and_DERBY-2480.diff, testOpenOfMissingDatabase.java
>
>
> Repeated calls to
> java.sql.DriverManager.getConnection("jdbc:derby:C:\\DOES_NOT_EXIST") leak
> memory and eventually lead to an OutOfMemoryError.
> This bug is similar to DERBY-1947 in that ContextManager objects are not
> getting removed from the HashSet. The attached test program demonstrates the
> issue. When run with VM options -Xms8m -Xmx8m, it throws an OutOfMemoryError
> after 19022 calls to DriverManager.getConnection.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
