Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 15960 invoked from network); 22 Aug 2006 13:54:31 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 22 Aug 2006 13:54:31 -0000 Received: (qmail 72990 invoked by uid 500); 22 Aug 2006 13:54:31 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 72967 invoked by uid 500); 22 Aug 2006 13:54:31 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 72958 invoked by uid 99); 22 Aug 2006 13:54:31 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 22 Aug 2006 06:54:30 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from [209.237.227.198] (HELO brutus.apache.org) (209.237.227.198) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 22 Aug 2006 06:54:30 -0700 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id E06217142F9 for ; Tue, 22 Aug 2006 13:51:14 +0000 (GMT) Message-ID: <33439501.1156254674916.JavaMail.jira@brutus> Date: Tue, 22 Aug 2006 06:51:14 -0700 (PDT) From: "Mayuresh Nirhali (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Commented: (DERBY-418) outofmemory error when running large query in autocommit=false mode In-Reply-To: <212615905.1120164119028.JavaMail.jira@ajax.apache.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N [ http://issues.apache.org/jira/browse/DERBY-418?page=comments#action_12429709 ] Mayuresh Nirhali commented on DERBY-418: ---------------------------------------- Thanks Knut for pointing that out. I did not mean to provide a patch for this JIRA, but just wanted to try out a suggested approach. I have corrected this error and now the trial piece of code looks like, public void addActivation(Activation a) { acts.addElement(a); try { if (acts.size() > 20) { for (int i = acts.size() - 1; i >= 0; i--) { Activation a1 = (Activation) acts.elementAt(i); if (!a1.isInUse()) { a1.close(); } } //for } } catch(StandardException e) { } if (SanityManager.DEBUG) { if (SanityManager.DEBUG_ON("memoryLeakTrace")) { if (acts.size() > 20) System.out.println("memoryLeakTrace:GenericLanguageContext:activations " + acts.size()); } } } I have tried your code snippet with this along with the repro and did not see any regressions. However, the OOME is still seen. As mentioned in my earlier comment, the main issue seems to be with the Finalizer thread behaviour. I guess there are 2 parts to this issue. 1. Make sure the inUse field is synchronized 2. Close activation objects either directly from EmbedRS.finalize method or indirectly as per the change in GenLCC.addActivation method. > outofmemory error when running large query in autocommit=false mode > ------------------------------------------------------------------- > > Key: DERBY-418 > URL: http://issues.apache.org/jira/browse/DERBY-418 > Project: Derby > Issue Type: Bug > Components: Store > Affects Versions: 10.1.1.0 > Environment: I can reproduce this problem on Win2k/ T42 laptop. jdk141. > Reporter: Sunitha Kambhampati > Assigned To: Mayuresh Nirhali > Fix For: 10.2.1.0 > > Attachments: AutoCommitTest.java > > > On the derby-user list, Chris reported tihs problem with his application and also a repro for the problem. I am logging the jira issue so it doesnt get lost in all the mail. (http://www.mail-archive.com/derby-user@db.apache.org/msg01258.html) > ------from chris's post---------- > I'm running a set of ~50000 queries on one table, using inserts and updates, and i want to be able to roll them back so i turned off autocommit using setAutoCommit(false). As the update runs, the memory used by the JVM increases continually until i get the following exception about 20% of the way through: > ERROR 40XT0: An internal error was identified by RawStore module. > at org.apache.derby.iapi.error.StandardException.newException(StandardException.java) > at org.apache.derby.impl.store.raw.xact.Xact.setActiveState(Xact.java) > at org.apache.derby.impl.store.raw.xact.Xact.openContainer(Xact.java) > at org.apache.derby.impl.store.access.conglomerate.OpenConglomerate.init(OpenConglomerate.java) > at org.apache.derby.impl.store.access.heap.Heap.open(Heap.java) > at org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(RAMTransaction.java) > at org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(RAMTransaction.java) > at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getDescriptorViaIndex(DataDictionaryImpl.java) > at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.locateSchemaRow(DataDictionaryImpl.java) > at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getSchemaDescriptor(DataDictionaryImpl.java) > at org.apache.derby.impl.sql.compile.QueryTreeNode.getSchemaDescriptor(QueryTreeNode.java) > at org.apache.derby.impl.sql.compile.QueryTreeNode.getSchemaDescriptor(QueryTreeNode.java) > at org.apache.derby.impl.sql.compile.FromBaseTable.bindTableDescriptor(FromBaseTable.java) > at org.apache.derby.impl.sql.compile.FromBaseTable.bindNonVTITables(FromBaseTable.java) > at org.apache.derby.impl.sql.compile.FromList.bindTables(FromList.java) > at org.apache.derby.impl.sql.compile.SelectNode.bindNonVTITables(SelectNode.java) > at org.apache.derby.impl.sql.compile.DMLStatementNode.bindTables(DMLStatementNode.java) > at org.apache.derby.impl.sql.compile.DMLStatementNode.bind(DMLStatementNode.java) > at org.apache.derby.impl.sql.compile.ReadCursorNode.bind(ReadCursorNode.java) > at org.apache.derby.impl.sql.compile.CursorNode.bind(CursorNode.java) > at org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java) > at org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java) > at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConnectionContext.java) > at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java) > at org.apache.derby.impl.jdbc.EmbedStatement.executeQuery(EmbedStatement.java) > at vi.hotspot.database.DataInterface._query(DataInterface.java:181) > at vi.hotspot.database.DataInterface.query(DataInterface.java:160) > at vi.hotspot.database.UpdateManager.updatePartialTable(UpdateManager.java:518) > at vi.hotspot.database.UpdateManager.updatePartialTables(UpdateManager.java:619) > at vi.hotspot.database.UpdateManager.run(UpdateManager.java:924) > at java.lang.Thread.run(Thread.java:534) > vi.hotspot.exception.ServerTransactionException > at vi.hotspot.database.UpdateManager.updatePartialTable(UpdateManager.java:555) > at vi.hotspot.database.UpdateManager.updatePartialTables(UpdateManager.java:619) > at vi.hotspot.database.UpdateManager.run(UpdateManager.java:924) > at java.lang.Thread.run(Thread.java:534) > Derby is running in standalone mode. -- 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