Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 70352 invoked from network); 20 Apr 2007 13:53:45 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 20 Apr 2007 13:53:45 -0000 Received: (qmail 61461 invoked by uid 500); 20 Apr 2007 13:53:43 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 61434 invoked by uid 500); 20 Apr 2007 13:53:43 -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 61408 invoked by uid 99); 20 Apr 2007 13:53:43 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 20 Apr 2007 06:53:43 -0700 X-ASF-Spam-Status: No, hits=-100.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO brutus.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 20 Apr 2007 06:53:35 -0700 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id D4C05714071 for ; Fri, 20 Apr 2007 06:53:15 -0700 (PDT) Message-ID: <25957655.1177077195868.JavaMail.jira@brutus> Date: Fri, 20 Apr 2007 06:53:15 -0700 (PDT) From: "Dag H. Wanvik (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Updated: (DERBY-1947) OutOfMemoryError after repeated calls to boot and shutdown a database In-Reply-To: <2419779.1160451860731.JavaMail.root@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/DERBY-1947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik updated DERBY-1947: --------------------------------- Attachment: DERBY-1947-4.stat DERBY-1947-4.diff This version of the patch, DERBY-1947-4.* supercedes all earlier versions. It removes the call to close() from the finalizer of EmbedConnection for nested connection objects introduced in earlier versions of this patch as it is not strictly necessary. This solves the deadlock issue. suites.All and derbyall + the repro run cleanly with Sun 1.4 on Solaris. I have verified the repro and ProcudureInTriggerTest against Sun 1.4 and IBM 1.5 on Linux as well. Unless I get feedback on this version I will commit it on Monday. > OutOfMemoryError after repeated calls to boot and shutdown a database > --------------------------------------------------------------------- > > Key: DERBY-1947 > URL: https://issues.apache.org/jira/browse/DERBY-1947 > Project: Derby > Issue Type: Bug > Components: Services > Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6 > Environment: Any > Reporter: Rajesh Kartha > Assigned To: Dag H. Wanvik > Attachments: DERBY-1947-1.diff, DERBY-1947-1.stat, DERBY-1947-2.diff, DERBY-1947-2.stat, DERBY-1947-3.diff, DERBY-1947-3.stat, DERBY-1947-4.diff, DERBY-1947-4.stat, HeapAnalysis_op.jpg, ProcedureInTriggerTest-threadstacks.txt, testEmbedAndClient.java > > > I came across this OOM issue while running some system tests involving > backup and restore against Derby. The test is expected to run forever but > using the default heap space it runs into OOM within 2 days. I earlier mentioned about this > in my reply to the 10.2.1.6 vote - http://www.nabble.com/Re%3A--VOTE--10.2.1.6-release-p6650528.html > Also there has been some discussions on the list on the related topic: > http://issues.apache.org/jira/browse/DERBY-23 and > http://www.nabble.com/question-about-shutdown-tf2300504.html > Basic Analysis: > -------------------- > Wrote a simple Java app (attached to this issue) that booted and shutdown the same > database multiple times. Depending on the heapsize the program ran into the > OOM at some point, as expected. Some heap dump analysis using the IBM HeapAnalyzer > and revealed that the HashSet (allContexts) within org.apache.derby.iapi.services.context.ContextService > class seemed to be location of the leak (snapshot of the heapanalysis attached). > A little bit of debugging shows that: > - for every:connection two ContextManager objects (say, cm1, cm2) are added to the HashSet > - for every shutdown a new ContextManager object (say, cm3) is added and two objects are removed > - the object removed are cm2 and cm3 - in that sequence > - but the object cm1 gets left behind > This happens for every connect/shutdown sequence and since one of the ContextManager objects added to the > HashSet is not removed as a part of the cleanup, it contributes to growth in memory usage, hence > an OOM eventually. > For example: > ============ > A 64M heap could allow about 1107 iterations of connect/shutdown only before running into OOM and > created 1108 un-used ContextManager objects in the memory. > java -Xmx64M testEmbedAndClient > ++++Debug: add() Size of allContexts HashSet obj= 1 > ----Debug: remove() Size of allContexts HashSet obj= 0 > ++++Debug: add() Size of allContexts HashSet obj= 1 > ----Debug: remove() Size of allContexts HashSet obj= 0 > ++++Debug: add() Size of allContexts HashSet obj= 1 > ++++Debug: add() Size of allContexts HashSet obj= 2 > ==== Database booted in embedded ==== > ++++Debug: add() Size of allContexts HashSet obj= 3 > ----Debug: remove() Size of allContexts HashSet obj= 2 > ----Debug: remove() Size of allContexts HashSet obj= 1 > ==== Shutdown complete in embedded ==== > ++++Debug: add() Size of allContexts HashSet obj= 2 > ++++Debug: add() Size of allContexts HashSet obj= 3 > ==== Database booted in embedded ==== > ++++Debug: add() Size of allContexts HashSet obj= 4 > ----Debug: remove() Size of allContexts HashSet obj= 3 > ----Debug: remove() Size of allContexts HashSet obj= 2 > .. > .. > .. > ==== Database booted in embedded ==== > ++++Debug: add() Size of allContexts HashSet obj= 1109 > ----Debug: remove() Size of allContexts HashSet obj= 1108 > ----Debug: remove() Size of allContexts HashSet obj= 1107 > ==== Shutdown complete in embedded ==== > ++++Debug: add() Size of allContexts HashSet obj= 1108 > ++++Debug: add() Size of allContexts HashSet obj= 1109 > ----Debug: remove() Size of allContexts HashSet obj= 1108 > java.sql.SQLException: Failed to start database 'testdb', see the next exception > for details. > at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45) > at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:89) > at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:95) > at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Util.java:174) > at org.apache.derby.impl.jdbc.EmbedConnection.newSQLException(EmbedConnection.java:1985) > at org.apache.derby.impl.jdbc.EmbedConnection.bootDatabase(EmbedConnection.java:1649) > at org.apache.derby.impl.jdbc.EmbedConnection.(EmbedConnection.java:223) > at org.apache.derby.impl.jdbc.EmbedConnection30.(EmbedConnection30.java:73) > at org.apache.derby.jdbc.Driver30.getNewEmbedConnection(Driver30.java:74) > at org.apache.derby.jdbc.InternalDriver.connect(InternalDriver.java:210) > ----Debug: remove() Size of allContexts HashSet obj= 1107 > at org.apache.derby.jdbc.AutoloadedDriver.connect(AutoloadedDriver.java:117) > at java.sql.DriverManager.getConnection(DriverManager.java:525) > at java.sql.DriverManager.getConnection(DriverManager.java:193) > at testEmbedAndClient.testInEmbedded(testEmbedAndClient.java:40) > at testEmbedAndClient.main(testEmbedAndClient.java:19) > java.lang.OutOfMemoryError: Java heap space > OOM happened after 1107 iterations -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.