db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John H. Embretsen (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1564) wisconsin.sql test failed in DerbyNet framework, VM for network server got OutOfMemoryError
Date Thu, 27 Jul 2006 14:36:15 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1564?page=comments#action_12423846 ] 
            
John H. Embretsen commented on DERBY-1564:
------------------------------------------

In the DerbyNet (and DerbyNetClient) framework the test harness spawns two new JVMs when running
the lang/wisconsin.java test. One JVM is the Network Server JVM, and the other is the wisconsin
test itself. It seems to me that the failure reported in this Jira-issue is caused by an OutOfMemoryError
in the Network Server JVM, since the error is reported in the DerbyNet.err file only. 

Hence, regression testers need to be aware of which heap size values actually has any effect
on both JVMs when using the jvmflags property. Because of the complexity of the test harness,
understanding this is not necessarily a trivial task, especially since the jvmflags property
has a different effect in version 10.1.x.x vs. version 10.2.x.x.

Kathey recommended in a previous comment to run the test with reduced heap sizes, and compare
results for 10.1 and 10.2. I have a few observations/recommendations in that regard, based
on test runs with the Sun 1.5 JVM (using "jmap -heap <jvmid>" to get the actual max
size of the JVM heap) and Derby versions 10.1.3.1 and 10.2.0.4:

10.1.3.1 testing:
---------------------------

Test name: lang/wisconsin.sql
Example heap size: 12 MB

- Use -Djvmflags="-ms12m -mx12m" (including quotes) (12M also works; these values are case
insensitive).

- By using -Djvmflags=-mx12m, the Network Server process fails ("Incompatible initial and
maximum heap sizes specified") since the harness automatically adds an -ms16777216 (initial
heap size 16 MB), which is higher than the max heap size of 12 MB. Hence, using -mx only in
jvmflags works only if the value of -mx is 16m or larger.

- By using -Djvmflags="-Xms12 -Xmx12m", the harness automatically adds "- ms16777216 -mx33554432"
(excluding quotes) when starting the server JVM. These options are added _after_ the -Xms
and -Xmx options , thus overriding the 12 MB values so that the network server will have a
max heap size of 32 MB instead of 12 MB.

- Default heap size on my machine seems to be 64 MB for both JVMs. I don't know why the wisconsin_app.properties
jvmflags (-ms32M -mx128M) are not used.


10.2.0.4 testing:
---------------------------

Test name: lang/wisconsin.java
Example heap size: 12 MB

- Use -Djvmflags=-Xms12m^-Xmx12m

The harness adds "-ms32M -mx128M" (from wisconsin_app.properties) automatically to the server
JVM command, but puts it _before_ the jvmflags from the command line. Using both -Xms and
-Xmx ensures that the values from wisconsin_app.properties are overridden, probably thanks
to DERBY-1091.

- By using -Djvmflags=-Xmx12m, the "Incompatible initial and maximum heap sizes specified"
problem from above reappears, since the max value of 12 MB is smaller than the initial value
of 32 MB.

 - By using  -Djvmflags="-ms12m -mx12m", the server JVM heap size settings from the command
line are overridden by the settings set by the test harness (a test harness bug?). The resulting
java command line flags for the server JVM is: "java -ms32M -mx128M -ms12m -mx12m -ms16777216
-mx33554432", and the last value is used, which for max heap size is 33554432, which is 32
MB. Hence, the test may pass when it would have failed with correct jvm flags.

- It seems like the wisconsin_app.properties jvmflags values are overridden by the above mentioned
server flags (-ms16777216 -mx33554432) when running the 10.2 version of the test without specifying
heap size on the command line.


I got the flags passed on by the test harness by adding -Dverbose=true when starting the test
via RunTest.

I hope this is useful when/if someone decides to start following the testing approach suggested
by Kathey. I will run some tests myself, and will post the results here (or I will create
a wiki page), presumably tomorrow, so that we may know more about what's going on.

Please yell if you think I have made any errors regarding the test harness and its jvmflags
property, or drawn any wrong conclusions.


> wisconsin.sql test failed in DerbyNet framework, VM for network server got OutOfMemoryError
> -------------------------------------------------------------------------------------------
>
>                 Key: DERBY-1564
>                 URL: http://issues.apache.org/jira/browse/DERBY-1564
>             Project: Derby
>          Issue Type: Bug
>          Components: Network Server, Test
>    Affects Versions: 10.2.0.0
>         Environment: Solaris Sparc, Java 6, running in a Solaris Zone. DerbyNet framework.
>            Reporter: Andreas Korneliussen
>            Priority: Critical
>         Attachments: wisconsin.tar.gz
>
>
> The wisconsin test failed when running it in DerbyNet framework. No output in the outfile.
The DerbyNet.err file has one message:
> Exception in thread "Thread-2" java.lang.OutOfMemoryError: Java heap space
> The test was run against 10.2.0.4 snapshot release.

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

        

Mime
View raw message