[ http://issues.apache.org/jira/browse/DERBY-210?page=all ]
John H. Embretsen updated DERBY-210:
------------------------------------
Attachment: runtimeinfo_DOTS-OOME.txt
I attached runtimeinfo_DOTS-OOME.txt, which is runtimeinfo
(org.apache.derby.drda.NetworkServerControl runtimeinfo) collected a while
after the first OutOfMemoryError (OOME) on the server, from the last failed
DOTS test run, as discussed in the e-mail thread
http://www.nabble.com/-jira-Updated%3A-%28DERBY-210%29-Network-Server-will-leak-prepared-statements-if-not-explicitly-closed-by-the-user-until-the-connection-is-closed-t1219222.html#a3271800
The first OOME occurred after roughly 56 hours this time. I have collected
similar runtimeinfos from previous failed test runs.
(I do not currently have a runtimeinfo from the exact time when the first OOME
occurres.)
Most of the statements seen in runtimeinfo are of the type
SELECT SELLERID,DESCRIPTION,BID_PRICE,START_TIME,END_TIME,BID_COUNT FROM ITEM
WHERE ITEMID = 'ITEM664222'
which seem to be unprepared statements, e.g.
rs = stmt.executeQuery(getItemSQL + "'" + itemID + "'");
that are not always properly closed (see dots.advcase.ATCJ2.java).
I guess that in this case the problem is a lack of closing all statements
properly, regardless of whether they are prepared or not (?).
> 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,
> StatementStress.java, 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, runtimeinfo_DOTS-OOME.txt
>
> 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
