[
http://issues.apache.org/jira/browse/DERBY-418?page=comments#action_12429668 ]
Mayuresh Nirhali commented on DERBY-418:
----------------------------------------
I tried the approach suggested by Dan in DERBY-1142, and my version of change
looks like as below,
In GenericLanguageConnectionContext,
public void addActivation(Activation a) {
acts.addElement(a);
+ try {
+ if (acts.size() > 20) {
+ resetActivations(false);
+ }
+ } catch(StandardException e) {
+ }
+
if (SanityManager.DEBUG) {
if (SanityManager.DEBUG_ON("memoryLeakTrace")) {
if (acts.size() > 20)
System.out.println("memoryLeakTrace:GenericLanguageContext:activations " +
acts.size());
}
}
}
I thought it will be better to use the method resetActivations as it is meant
to do the desired business for us. ( let me know if there are any negative
implications of using this method here)
This approach did not solve the OOME but differed it for sometime. The effect
of this change is equal to the effect of having singleUseActivation.close in
the finalize method of EmbedRS, as suggested earlier.
Further, and importantly, I found that there still exist some Activation
objects with inUse=true. I guess there is a synchronization issue here due to
which EmbedRS.finalize is not called for all the objects, thus not marking them
unused. On several runs, the worst case I found is that for 100 such select
queries about 10% activation objects still stay on the heap. So, as the
finalize method is not executed for many objects, the activation objects are
not freed. Here, it is irrelevent if they are closed directly from within the
finalize method or indirectly by first just marking them unused.
I ran these tests on both jdk1.6 and jdk1.5.
any thoughts on behaviour of finalizer thread in this context.
any inputs on synchronizing the markunused operation ??
> 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/[email protected]/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
