Community
Participate
Working Groups
>Running the jpa lrg (trunk>ant test-jpa) will cause an out of memory error on at least 3 machines when run on XP using the 32-bit SUN 1.6.0_07 JVM. This issue is similar to the one fixed in bug# 282012 for 32/64 bit JVM's for the core lrg. >See attached JConsole.exe screen captures before/after the fix >Note: this test runs fine on a JRockit 1.6 JVM and the 64-bit version of the SUN 1.6.0_14 JVM >logs before change : OOME ------------------ [junit] [EL Finer]: 2009-10-05 11:25:15.109--UnitOfWork(11140666)--Thread(Thread[main,5,main])--release un it of work [junit] [EL Finer]: 2009-10-05 11:25:15.109--ClientSession(10241753)--Thread(Thread[main,5,main])--client released [junit] Tests run: 1333, Failures: 0, Errors: 0, Time elapsed: 1,391.953 sec [echo] jpatest.build.location='C:\view_w342e\jpa\eclipselink.jpa.test' [echo] modelgen.processor.jar='eclipselink-jpa-modelgen_2.0.0.qualifier.jar' generate-report: BUILD FAILED C:\view_w342e\build.xml:705: The following error occurred while executing this line: C:\view_w342e\jpa\eclipselink.jpa.test\build.xml:752: The following error occurred while executing this line: C:\view_w342e\jpa\eclipselink.jpa.test\build.xml:1130: java.lang.OutOfMemoryError: Java heap space Total time: 24 minutes 32 seconds C:\view_w342e>java -version java version "1.6.0_07" Java(TM) SE Runtime Environment (build 1.6.0_07-b06) Java HotSpot(TM) Client VM (build 10.0-b23, mixed mode, sharing) >Workaround ------------------ 1) The usual method of increasing the memory heap space from 512 to 1024 for the preceeding test process does not work in this case - like it does for the core LRG (running on _14) >jpa/eclipselink.jpa.test/build.xml:1074 <junit printsummary="yes" haltonfailure="yes" fork="yes" showoutput="true" maxmemory="1024m" dir="${eclipselink.jpa.test}/${run.dir}"> - tested with the latest 16 build - Upgrade the JVM from 1.6.0_07 to 1.6.0_16 Still failing with OOME >For now - use a different JVM like the IBM J9 or JRocket JVM C:\opt\jrmc310_160\bin>java -version java version "1.6.0_11" Java(TM) SE Runtime Environment (build 1.6.0_11-b03) BEA JRockit(R) (build R27.6.3-40_o-112056-1.6.0_11-20090318-2104-windows-x86_64, compiled mode) > or 32 bit U:\>java -version java version "1.6.0_05" Java(TM) SE Runtime Environment (build 1.6.0_05-b13) BEA JRockit(R) (build R27.6.0-50_o-100423-1.6.0_05-20080626-2105-windows-ia32, compiled mode)
Created attachment 148820 [details] JConsole memory heap screencap OOME with XML report gen spike for JPA build.xml:1072
>currently now working on this issue - as my primary development environment has switched to 64-bit - which has no issues with this test suite. Other developers are however still experiencing this issue running in 32-bit mode. >workaround also is to use the testing browser which does not generate a report - and ignore the html generation error and parse the XML file manually.
>We are limitied by the 2GB RAM footprint of some of the build servers - this 1536 fix will only run on 4GB XP machines - keep it at a max of 1024 and add a variable for developers to bump it up to 1536 if they get an OOME
Created attachment 150769 [details] Post 56xx fix for OOME for 64-bit JVMs running JPA LRG in ant - a formal test.properties user definable property is required - I am not checking this local change in >Failing with an OOME or "Forked Java VM exited abnormally" on a 64 bit SUN JVM on a machine with 12GB Fix is to increase the heap from 512 to 2048 If I increase the heap from 512 to 2048 (for 64 bit JVM's only with over 4GB ram) I no longer crash running the ant report it generates the following 1605 1 2 99.81% 1457.861 >We will need a user assignable build property in the future for this to accomidate either 32 or 64 bit JVM's.
>see details at http://dev.eclipse.org/mhonarc/lists/eclipselink-dev/msg03278.html
Is this still occurring? Is the variable still needed? I'm asking because the nightly builds have been running on a 64-bit jvm for quite a while and I've seen no specific out of memory issues.
>The XML processing at the end of the build has been running fine within 1k since 2010 at least
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink
