Return-Path: X-Original-To: apmail-db-derby-dev-archive@www.apache.org Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id A2FBD4C7D for ; Sat, 18 Jun 2011 01:44:11 +0000 (UTC) Received: (qmail 65104 invoked by uid 500); 18 Jun 2011 01:44:11 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 65067 invoked by uid 500); 18 Jun 2011 01:44:11 -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 65058 invoked by uid 99); 18 Jun 2011 01:44:11 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 18 Jun 2011 01:44:11 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=5.0 tests=ALL_TRUSTED,T_RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [140.211.11.116] (HELO hel.zones.apache.org) (140.211.11.116) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 18 Jun 2011 01:44:08 +0000 Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116]) by hel.zones.apache.org (Postfix) with ESMTP id 5CCC041F0C4 for ; Sat, 18 Jun 2011 01:43:47 +0000 (UTC) Date: Sat, 18 Jun 2011 01:43:47 +0000 (UTC) From: "Mamta A. Satoor (JIRA)" To: derby-dev@db.apache.org Message-ID: <1739624908.17436.1308361427376.JavaMail.tomcat@hel.zones.apache.org> In-Reply-To: <1207090802.6294.1308130847299.JavaMail.tomcat@hel.zones.apache.org> Subject: [jira] [Commented] (DERBY-5277) Intermittent OutOfMemoryErrors in BasicSetup.testTriggersWithLOBcolumns() MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/DERBY-5277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13051435#comment-13051435 ] Mamta A. Satoor commented on DERBY-5277: ---------------------------------------- Hi Knut, I have been looking at this jira for sometime and found out the reason behind the problem. First of all, you are correct that if the upgrade is from 10.7.1.1 to trunk, we do not run into OOM with the LOB columns if those LOB columns are not needed by the triggering sql and firing triggers. This is because 10.7.1.1 collects information about column in trigger action and hence trunk can be smart about what columns should be read. As for all the other releases, none of them collect information about columns in trigger action and hence trigger firing sql decides to read all the columns including the LOBs even if they are not needed. At the time of upgrade, the trigger SPSes get marked invalid correctly.But they do not get recompiled until the time of actual trigger firing. UPDATE sql decides what columns it should read based on what it needs and what the firing triggers will need. When UPDATE sql is collecting all this informaiton about firing triggers, they are not get recompiled and hence UPDATE sql used incorrect information from the invalid triggers.I will work on this jira further to see how it can be resolved. One option would be to have UPDATE sql recognize the fact that the triggers are invalid and hence they should be recompiled first before UPDATE looks at them to determine what columns are needed by the triggers. As you noticed in the jira, this problem is intermittent because it all depends on how much memory upgrade suite has to run the tests. I guess I must have had enough memory to not run into OOM when I ran the upgrade suite few times on my machine. One of the things I had wondered about while adding the test in BasicSetup.testTriggersWithLOBcolumns if we could run upgrade suite with lower memory(something like lowmem suite). Better yet would be to just run testTriggersWithLOBcolumns test with lowmem. I will appreciate if anyone knows of a way of doing that in junit framework. > Intermittent OutOfMemoryErrors in BasicSetup.testTriggersWithLOBcolumns() > ------------------------------------------------------------------------- > > Key: DERBY-5277 > URL: https://issues.apache.org/jira/browse/DERBY-5277 > Project: Derby > Issue Type: Bug > Components: Test > Affects Versions: 10.9.0.0 > Reporter: Knut Anders Hatlen > Assignee: Mamta A. Satoor > > Seen many times in the JDK 7 tests lately, and also in the Tinderbox. First occurrence was here: http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.7/testing/testlog/sol32/1134678-suitesAll_diff.txt > (There had been no commits in the last two days before this test run, so it's difficult to say if a recent change caused it.) > The test case has a comment that says that it should never read the LOB into memory, but according to the stack trace, that's exactly what's happening: > Caused by: java.lang.OutOfMemoryError: Java heap space > at org.apache.derby.iapi.types.SQLBinary.readFromStream(Unknown Source) > at org.apache.derby.iapi.types.SQLBinary.readExternal(Unknown Source) > at org.apache.derby.iapi.types.SQLBinary.getValue(Unknown Source) > at org.apache.derby.iapi.types.SQLBinary.loadStream(Unknown Source) > at org.apache.derby.impl.sql.execute.UpdateResultSet.objectifyStream(Unknown Source) > at org.apache.derby.impl.sql.execute.UpdateResultSet.collectAffectedRows(Unknown Source) > at org.apache.derby.impl.sql.execute.UpdateResultSet.open(Unknown Source) > at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown Source) > at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) > at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source) > at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source) > at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(Unknown Source) > at org.apache.derbyTesting.functionTests.tests.upgradeTests.BasicSetup.testTriggersWithLOBcolumns(BasicSetup.java:854) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira