db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John H. Embretsen (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-2480) DriverManager.getConnection leaks memory when connecting to a non-existent database
Date Tue, 17 Apr 2007 12:47:15 GMT

     [ 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

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

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:,,,,,,,
>         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.

View raw message