[ http://issues.apache.org/jira/browse/DERBY-210?page=comments#action_12366947 ]
Deepa Remesh commented on DERBY-210: ------------------------------------ Kathey, please see if the following answers your questions: 2) Not sure about these. How do they get cleaned up? The statement and result sets for generated keys query get cleaned up in Statement.markClosed() by call to markPreparedStatementForAutoGeneratedKeysClosed() method. This method calls markClosed on the auto-generated keys statement, which will ensure this statement and its result sets are cleaned on client side. The cleanup on server happens when section is re-used. 1) Somehow all of this causes the section to be reused. So, while we won't have immediate cleanup on the server, it will happen if the section is reused. Can you explain this process a bit more? As part of Statement.markClosed(), markClosedOnServer() method gets called. This method frees up the Section on the client. A stack is used to store the free sections. Hence, client driver will use this freed section for the next statement. When client driver re-uses the freed section, network server will find a statement with this section in its stmtTable and re-use the statement. This happens in Database.newDrdaStatement method in network server. Before re-using the statement, its close method is called. This close method cleans up the statement state and its current result set. All other resultsets in its result set table are freed. If you find these explanations are correct, I'll upload a revised version of patch4 with more comments. As you said, the code in patch4 will be not be fully covered by tests currently. The code in finalize method will be covered only after the patch which removes the memory leaks is reviewed and committed. This is in my next patch (patch5 - which removes the memory leaks + enable derbyStress test). I will run tests with patch4 + patch 5 and submit patch5, if that will help testing/reviewing. I think it would be good to do a long running test with patch4+patch5 before committing them. I'll be running the repro derbyStress.java with 1M prepared statements and will check client and server memory usage. Other than that, it may be good to run the patch through DOTS test. I do not have the DOTS setup. I would appreciate if John or anyone else has the setup for DOTS and will be willing to run the tests after I upload the new patches. Anyone has suggestions for other tests I can run to test this? > 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-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
