[ http://issues.apache.org/jira/browse/DERBY-756?page=comments#action_12363917 ]
Manish Khettry commented on DERBY-756: -------------------------------------- I ran the test case in the bug with a maximum heap size of 1 MB; atleast I specified -Xmx1m-- its possible that the JVM can't run with 1 MB and upped it to something more reasonable. Before the fix, we would run out of memory at about the 4000'th iteration. The good news is that we get to about 81,000 iterations. The bad news is that we still run out of memory. I changed the query from a count(distinct id) to a simple count(*) and the OutOfMemory error was thrown after about 81-82K executes. I think there is another memory leak (or two) in our system that we need to identify and fix. Is it safe to mark this bug closed and file another bug to track that issue or should I use this bug to track the memory leak that remains. If I don't hear from anyone, I'll mark this bug closed and file another one. > OutOfMemory Error on continous execution of select statement using COUNT() > and DISTINCT on same connection > ---------------------------------------------------------------------------------------------------------- > > Key: DERBY-756 > URL: http://issues.apache.org/jira/browse/DERBY-756 > Project: Derby > Type: Bug > Components: Demos/Scripts, JDBC, Network Client, Network Server, SQL > Versions: 10.0.2.1, 10.1.2.1 > Environment: Windows XP, Java 1.5.0_05, Derby network server 10.0.2.1, > 10.1.2.1, Derby heapsize 128m, IBM Universal JDBC driver > Reporter: Bill Chen > Assignee: Manish Khettry > Priority: Critical > Attachments: mem_leak.diff > > The OutOfMemory is thrown when I continously execute a sql statement on an > openned JDBC connection. A PreparedStatement and ResultSet is created on the > connection everytime and close after each execution. I suspect that the bug > is related to function COUNT() with keyword DISTINCT. For example, "select > count(distinct ID) from TEST where FLAG <> 2". It will be fine if DISTINCT is > not used, or select count(*) is used. > The exception like "Exception in thread "DRDAConnThread_2" > java.lang.OutOfMemoryError: Java heap space" could be thrown on Derby side, > or sometimes on client side. > Please find the test code and schema I used for testing: > create table: > CREATE TABLE Test > ( > ID BIGINT NOT NULL, > NAME VARCHAR(512) NOT NULL, > FLAG int, > CONSTRAINT PK_ID PRIMARY KEY (ID) > ); > insert data: > insert into TEST values (0, 'name0', 0); > insert into TEST values (1, 'name1', 1); > insert into TEST values (2, 'name2', 2); > Java client: > import java.sql.Connection; > import java.sql.PreparedStatement; > import java.sql.ResultSet; > import java.sql.DriverManager; > import java.sql.SQLException; > public class DerbyTest > { > static public void main(String args[]) throws Exception > { > Class.forName("com.ibm.db2.jcc.DB2Driver"); > Connection conn = null; > try > { > conn = > DriverManager.getConnection("jdbc:derby:net://localhost:1527/testDB", > "admin", "admin"); > for (int i = 0; i < 10000000; i++) > { > System.out.println("Query "+i); > String sql = "select count(distinct ID) from TEST where FLAG > <> 2"; > PreparedStatement pStmt = null; > ResultSet rs = null; > try > { > pStmt = conn.prepareStatement(sql); > rs = pStmt.executeQuery(); > if (rs.next()) > { > rs.getInt(1); > } > } > catch (SQLException e) > { > e.printStackTrace(); > } > finally > { > if (rs != null) > rs.close(); > if (pStmt != null) > pStmt.close(); > } > } > } > finally > { > if (conn != null) > conn.close(); > } > } > } -- 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
