[
https://issues.apache.org/jira/browse/DERBY-5726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13266463#comment-13266463
]
Knut Anders Hatlen commented on DERBY-5726:
-------------------------------------------
Hi Kathey,
I think this cleanup is important because memory leaks in the test framework
may prevent us from discovering real memory leaks in the product, and also
because if we keep letting new leaks into the tests, the amount of memory
required for running the tests will just keep growing.
For the record, with all the latest patches, suites.All now passes with 64MB
heap in my environment if I disable the following test cases:
TriggerTest
- testBlobInTriggerTable
Derby2017LayerATest
- cs_FailedStreamInsertCharBufferBoundaries
- cs_StreamInsertCharBufferBoundary
StatementJdbc30Test
- xtestMaxOpenStatementsWithQueryTimeout
ClobReclamationTest
- testBlobLinkedListReclamationOnRollback
When running the tests standalone, TriggerTest requires 165MB heap to pass, and
the other three tests pass with 85MB.
> Make it more difficult to forget calling super.tearDown() from
> BaseJDBCTestCase's subclasses
> --------------------------------------------------------------------------------------------
>
> Key: DERBY-5726
> URL: https://issues.apache.org/jira/browse/DERBY-5726
> Project: Derby
> Issue Type: Improvement
> Components: Test
> Affects Versions: 10.9.0.0
> Reporter: Knut Anders Hatlen
> Assignee: Knut Anders Hatlen
> Priority: Minor
> Attachments: d5726-1a.diff
>
>
> Many of the classes that extend BaseJDBCTestCase and override the tearDown()
> method, forget to call super.tearDown(), and thereby prevent resources from
> being freed after completion. We should add a mechanism that enforces the
> correct behaviour.
> If we were starting from scratch, we might have made
> BaseJDBCTestCase.tearDown() final and added a new overridable method that was
> called from BaseJDBCTestCase.tearDown() before it freed the statements and
> connections. Then there would be no way to prevent
> BaseJDBCTestCase.tearDown() from running in the subclasses. That would
> however require us to change all existing overrides of
> BaseJDBCTestCase.tearDown() (current count: 131), which would be a chunk of
> work.
> I'd rather suggest that we add an override of runBare() in BaseJDBCTestCase
> that asserts that the connection has been cleared out when a test case has
> completed successfully. Something like this:
> public void runBare() throws Throwable {
> super.runBare();
> // It's quite common to forget to call super.tearDown() when
> // overriding tearDown() in sub-classes.
> assertNull(
> "Connection should be null by now. " +
> "Missing call to super.tearDown()?", conn);
> }
> Then it would still be possible to forget to call super.tearDown(), but it
> would be discovered when trying to run the test.
> Adding the above method to BaseJDBCTestCase and running
> InternationalConnectTest gave this result:
> .....F.F....F
> Time: 5,748
> There were 3 failures:
> 1)
> testDriverManagerConnect(org.apache.derbyTesting.functionTests.tests.jdbcapi.InternationalConnectTest)junit.framework.AssertionFailedError:
> Connection should be null by now. Missing call to super.tearDown()?
> at
> org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:431)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> at junit.extensions.TestSetup.run(TestSetup.java:25)
> at
> org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
> 2)
> testBoundaries(org.apache.derbyTesting.functionTests.tests.jdbcapi.InternationalConnectTest)junit.framework.AssertionFailedError:
> Connection should be null by now. Missing call to super.tearDown()?
> at
> org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:431)
> (...)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
