Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <6221084.1159800200881.JavaMail.root@brutus>
Date: Mon, 2 Oct 2006 07:43:20 -0700 (PDT)
From: "John H. Embretsen (JIRA)" <derby-dev@db.apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-1910) OutOfMemoryError happens when
 jdbcapi/_Suite.junit was executed as DerbyNetClient (in jvm1.4.2)
In-Reply-To: <6747074.1159681159544.JavaMail.root@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

    [ http://issues.apache.org/jira/browse/DERBY-1910?page=comments#action_12439177 ] 
            
John H. Embretsen commented on DERBY-1910:
------------------------------------------

There seems to be a slight difference in memory usage between Windows/Linux and Solaris platforms, which is most likely why the suite so far does not fail on the Solaris platforms used in Sun's daily/nightly regression tests.

I ran the jdbcapi suite in the DerbyNetClient framework on both a Solaris 10 x86 machine and a Linux machine using JDK 1.4.2:

$ java -Dframework=DerbyNetClient org.apache.derbyTesting.functionTests.harness.RunTest jdbcapi/_Suite.junit

I monitored the memory usage of the junit.textui.TestRunner JVM by using the jstat tool. Both test runs reached a maximum tenured space usage of 60544 kB, but the linux JVM seemed to hit this limit a bit earlier than the Solaris JVM.

Default max heap size on 1.4.2 JVMs is 64 MB [1], so 60544 kB is probably the default max for the tenured space ("Eden" and the two survivor spaces occupy the rest of the heap, see [2]). On newer JVMs, the default max heap size usually depends on the hardware being used.

Further investigations are needed to determine the cause of this failure. It seems to me that there is an issue with JUnit tests all being run in the same JVM, resulting in old objects accumulating over time without being garbage collected, for some reason.


[1]: http://java.sun.com/docs/hotspot/gc1.4.2/#3.1.%20Total%20Heap|outline
[2]: http://java.sun.com/docs/hotspot/gc1.4.2/#2.%20Generations|outline


> OutOfMemoryError happens when jdbcapi/_Suite.junit was executed as DerbyNetClient (in jvm1.4.2)
> -----------------------------------------------------------------------------------------------
>
>                 Key: DERBY-1910
>                 URL: http://issues.apache.org/jira/browse/DERBY-1910
>             Project: Derby
>          Issue Type: Bug
>         Environment: naka@rufelza:~/derby/test/20061001_2$ cat /proc/version 
> Linux version 2.6.12-1-386 (horms@tabatha.lab.ultramonkey.org) (gcc version 4.0.2 20050917 (prerelease) (Debian 4.0.1-8)) #1 Tue Sep 27 12:41:08 JST 2005
> naka@rufelza:~/derby/test/20061001_2$ java -version
> java version "1.4.2_10"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_10-b03)
> Java HotSpot(TM) Client VM (build 1.4.2_10-b03, mixed mode)
>            Reporter: Tomohito Nakayama
>         Assigned To: Fernanda Pizzorno
>
> I found this phenomena at my environment.
> naka@rufelza:~/derby/test/20061001_2$ runNetClientTest.sh jdbcapi/_Suite.junit
> /home/naka/derby/dev/trunk/jars/sane/derby.jar:
> /home/naka/derby/dev/trunk/jars/sane/derbytools.jar:
> /home/naka/derby/dev/trunk/jars/sane/derbynet.jar:
> /home/naka/derby/dev/trunk/jars/sane/derbyclient.jar:
> /home/naka/derby/dev/trunk/jars/sane/derbyrun.jar:
> /home/naka/derby/dev/trunk/jars/sane/derbyTesting.jar:
> /home/naka/derby/dev/trunk/tools/java/jakarta-oro-2.0.8.jar:
> /home/naka/derby/dev/trunk/jars/sane/derbyLocale_de_DE.jar:
> /home/naka/derby/dev/trunk/jars/sane/derbyLocale_es.jar:
> /home/naka/derby/dev/trunk/jars/sane/derbyLocale_fr.jar:
> /home/naka/derby/dev/trunk/jars/sane/derbyLocale_it.jar:
> /home/naka/derby/dev/trunk/jars/sane/derbyLocale_ja_JP.jar:
> /home/naka/derby/dev/trunk/jars/sane/derbyLocale_ko_KR.jar:
> /home/naka/derby/dev/trunk/jars/sane/derbyLocale_pt_BR.jar:
> /home/naka/derby/dev/trunk/jars/sane/derbyLocale_zh_CN.jar:
> /home/naka/derby/dev/trunk/jars/sane/derbyLocale_zh_TW.jar:
> /home/naka/derby/dev/trunk/tools/java/junit.jar:
> /home/naka/derby/dev/trunk/tools/java/db2jcc.jar:
> /home/naka/derby/dev/trunk/tools/java/db2jcc_license_c.jar:.
> console.encoding:null file.encoding:ISO-8859-1 derby.ui.codeset: null
> *** Start: _Suite jdk1.4.2_10 DerbyNetClient 2006-10-01 14:19:52 ***
> Initialize for framework: DerbyNetClient
> startServer = false. Bypass server startup
> java -Duser.language=en -Duser.country=US -Dderby.system.home=/home/naka/derby/test/20061001_2/DerbyNetClient/_Suite -Dderby.infolog.append=true -Dframework=DerbyNetClient -Djava.security.manager -Djava.security.policy=/home/naka/derby/test/20061001_2/derby_tests.policy -DderbyTesting.clientjar=file:/home/naka/derby/dev/trunk/jars/sane/ -DderbyTesting.codejar=file:/home/naka/derby/dev/trunk/jars/sane/ -DderbyTesting.testjar=file:/home/naka/derby/dev/trunk/jars/sane/ -DderbyTesting.codedir=/home/naka/derby/dev/trunk/jars/sane -DderbyTesting.serverhost=localhost -DderbyTesting.clienthost=localhost junit.textui.TestRunner org.apache.derbyTesting.functionTests.tests.jdbcapi._Suite 
> The test should be running...
> About to execute: diff.exec( outName = /home/naka/derby/test/20061001_2/DerbyNetClient/_Suite.out,outDir = /home/naka/derby/test/20061001_2/DerbyNetClient,pwDiff = java.io.PrintWriter@12f0999,testOutName = _Suite,frameworkMaster = DerbyNetClient,jvmName = jdk14,iminor = 4,useprocess = true,systemdiff = false,canondir = null,canonpath = null)
> 0 add
> > .......................E....
> > There was 1 error:
> > 1) testClobAsciiWrite3Param(org.apache.derbyTesting.functionTests.tests.jdbcapi.LobStreamsTest)java.lang.OutOfMemoryError
> > FAILURES!!!
> > Tests run: 847,  Failures: 0,  Errors: 1
> Test Failed.
> *** End:   _Suite jdk1.4.2_10 DerbyNetClient 2006-10-01 14:22:01 ***
> This seems to be same as the error which was recorded in next test result.
> http://www.multinet.no/~solberg/public/Apache/DerbyJvm1.4/Limited/testSummary-451360.html
> Comparing results at http://www.multinet.no/~solberg/public/Apache/index.html, 
> this phenomena seems to happen when test was executed with jvm 1.4.2.

-- 
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