[
http://issues.apache.org/jira/browse/DERBY-210?page=comments#action_12368518 ]
John H. Embretsen commented on DERBY-210:
-----------------------------------------
Regarding patch derby-210-patch5-v1.diff:
I have not looked at the actual code, but I applied the patch to head of trunk
and started to run some tests:
* I started the previously mentioned DOTS test against trunk + patch, with same
settings (or as close as possible) as earlier. If it runs without error for
longer than 55 hours, it will be an improvement. I will publish the results
later.
* I created a smaller stand-alone application "inspired by" the really bad
parts of the DOTS test, and got very promising results (using sane jars):
* Without the patch, head of trunk (SVN 382319), OutOfMemoryError occured
in the derby server JVM after executing a little more than 11000 "bad" SELECT
statements.
* With the patch applied, the the server JVM was able to garbage collect
the PermSpace, and executed 100000 "bad" statements without error :)
I will do some more testing, but it's certainly looking good so far! :)
> Network Server will leak prepared statements if not explicitly closed by the
> user until the connection is closed
> ----------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-210
> URL: http://issues.apache.org/jira/browse/DERBY-210
> Project: Derby
> Type: Bug
> Components: Network Client
> Reporter: Kathey Marsden
> Assignee: Deepa Remesh
> Attachments: DOTS_ATCJ2_Derby-noPatch.png, DOTS_ATCJ2_Derby-withPatch.png,
> derby-210-patch1.diff, derby-210-patch2.diff, derby-210-patch2.status,
> derby-210-patch3.diff, derby-210-patch4-v2.diff, derby-210-patch4-v2.status,
> derby-210-patch4-v3.diff, derby-210-patch4-v3.status,
> derby-210-patch5-v1.diff, derby-210-patch5-v1.status,
> derby-210-v2-draft.diff, derby-210-v2-draft.status, derbyStress.java
>
> Network server will not garbage collect prepared statements that are not
> explicitly closed by the user. So a loop like this will leak.
> ...
> PreparedStatement ps;
> for (int i = 0 ; i < numPs; i++)
> {
> ps = conn.prepareStatement(selTabSql);
> rs =ps.executeQuery();
> while (rs.next())
> {
> rs.getString(1);
> }
> rs.close();
> // I'm a sloppy java programmer
> //ps.close();
> }
>
> To reproduce run the attached program
> java derbyStress
> Both client and server will grow until the connection is closed.
>
> It is likely that the fix for this will have to be in the client. The client
> does not send protocol to close the prepared statement, but rather reuses the
> PKGNAMCSN on the PRPSQLSTT request once the prepared statement has been
> closed. This is how the server knows to close the old statement and create a
> new one.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
