[
https://issues.apache.org/jira/browse/DERBY-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John H. Embretsen updated DERBY-2480:
-------------------------------------
Derby Info: (was: [Regression])
Affects Version/s: 10.0.2.0
10.0.2.1
10.1.1.0
10.1.2.1
10.1.3.1
10.2.1.6
Removing the regression flag and changing affects versions, as further testing
and an offline discussion with Kristian has resulted in the following findings:
* the issue can be reproduced against older Derby version as well, unless an
"invalid" database path (e.g. "C:\\whatever" on a unix system) AND a sane build
is used...
* If a sane build AND an invalid path is used, the booting attempts are
stopped by an assertion failure, and no OutOfMemoryError (OOME) is seen:
org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED serviceName
(/tmp/C:\DOES_NOT_EXIST) expected to equal getCanonicalServiceName(serviceName)
(null)
I am not yet sure if this is true for all versions of derby, or just some.
Further testing is needed.
* If a sane build and a valid path (e.g. "whateverDB") is used, we see the
memory leak on all versions/platforms tested so far.
* Also, if an insane build is used (regardless of path), we see the memory
leak on all versions/platforms tested so far. I have tested insane versions of
all official releases of Derby (and the current trunk) on Sun's 1.5.0_07 JVM.
With a max heap size of 32 MB the OOME occurs after about 49000 connection
attempts.
I have not tested all variants and combinations of Derby versions, JVMs,
database paths and operating systems, so I do not guarantee that these findings
are 100% precise...
> DriverManager.getConnection leaks memory using EmbeddedDriver on 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
> Reporter: Jeff Clary
> Priority: Minor
> Attachments: heap-server-Xmx32m.png, 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.
