db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John H. Embretsen (JIRA)" <derby-...@db.apache.org>
Subject [jira] Updated: (DERBY-210) Network Server will leak prepared statements if not explicitly closed by the user until the connection is closed
Date Wed, 08 Mar 2006 08:53:40 GMT
     [ 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


Mime
View raw message