[
https://issues.apache.org/jira/browse/DERBY-3316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12560009#action_12560009
]
Kathey Marsden commented on DERBY-3316:
---------------------------------------
For the adding it to the junit-all target option I think a few things have to
happen for it to be run as part of the nightlies.
1) Convert derbyStress.java to junit.
2) create a junit-lomem target and make it part of junit-all.
3) Fix junit-all so that it can run with the nightlies. DERBY-2045 + distribute
ant to the testing machines make nightly script changes etc.
I don't have time right now to pursue all of these, so am proposing we move
derbyStress.java back to derbyall for now until these goals can be accomplished
so at least the nightlies are testing the low memory scenarios. Right now the
test doesn't test much because it won't fail even if there is a leak. I think
it was moved to JDBCHarnessJavaTest prematurely. I'd like to move it back to
derbyall and open an issue to covert derbyStress outlining the issues. Does
that sound ok?
> Leak in client if ResultSet not closed
> --------------------------------------
>
> Key: DERBY-3316
> URL: https://issues.apache.org/jira/browse/DERBY-3316
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.2.1.6, 10.3.2.1, 10.4.0.0
> Reporter: Kathey Marsden
> Assignee: Kathey Marsden
> Fix For: 10.3.2.2, 10.4.0.0
>
> Attachments: derby-3316_diff.txt, derby-3316_diff2.txt,
> move_derbystress_to_derbyall_diff.txt, RepeatStatement.java
>
>
> If I run the attached program RepeatStatement.java with 32M of heap,
> I will get an OutOfMemory error in the client.
> java -Xmx32M RepeatStatement
> Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
> at
> org.apache.derby.client.am.Cursor.allocateCharBuffer(Cursor.java:1260)
> at
> org.apache.derby.client.net.NetStatementReply.parseSQLDTARDarray(NetStatementReply.java:1356)
> at
> org.apache.derby.client.net.NetStatementReply.parseQRYDSC(NetStatementReply.java:1207)
> at
> org.apache.derby.client.net.NetStatementReply.parseOpenQuery(NetStatementReply.java:479)
> at
> org.apache.derby.client.net.NetStatementReply.parseOPNQRYreply(NetStatementReply.java:223)
> at
> org.apache.derby.client.net.NetStatementReply.readOpenQuery(NetStatementReply.java:64)
> at
> org.apache.derby.client.net.StatementReply.readOpenQuery(StatementReply.java:50)
> at
> org.apache.derby.client.net.NetStatement.readOpenQuery_(NetStatement.java:153)
> at
> org.apache.derby.client.am.Statement.readOpenQuery(Statement.java:1396)
> at
> org.apache.derby.client.am.Statement.flowExecute(Statement.java:2001)
> at
> org.apache.derby.client.am.Statement.executeQueryX(Statement.java:421)
> at
> org.apache.derby.client.am.Statement.executeQuery(Statement.java:406)
> at RepeatStatement.testInsertAndSelect(RepeatStatement.java:31)
> at RepeatStatement.main(RepeatStatement.java:10)
> If I close the ResultSet or Statement it does not leak.
> This occurs on trunk and 10.2.1.6. It does however not run out of memory on
> 10.1.3.1, so appears to be a regression.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
