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] Updated: (DERBY-1614) Test harness overrides heap size settings when starting Network Server
Date Thu, 03 Aug 2006 10:55:14 GMT
     [ http://issues.apache.org/jira/browse/DERBY-1614?page=all ]

John H. Embretsen updated DERBY-1614:

    Attachment: DERBY-1614_v2.diff


Thanks for reviewing!

Attaching 'DERBY-1614_v2.diff', which replaces 'DERBY-1614_v1.diff'.

The only change from the previous patch is that the check for !jvmName.equals("jview") has
been removed.

PLEASE NOTE: Harness decision about setting heap size flags should change even more, see below!

I found a number of other references to jview in the harness code, but I have not removed
them (this is outside the scope of this Jira description):

./harness/RunList.java:726:             else if (javaCmd.equals("jview"))
./harness/RunList.java:727:                 jvmName = "jview";
./harness/RunList.java:743:             if ( (jvmName == null) || (jvmName.equals("jview"))
./harness/RunTest.java:973:             if ( (jvmName == null) || (jvmName.length()==0) ||
./harness/RunTest.java:995:             if ( (jvmName == null) || (!jvmName.equals("jview"))
./harness/NetServer.java:158:           if (jvmName.equals("jview"))
./harness/NetServer.java:159:               jvm.setJavaCmd("jview");
./harness/jvm.java:39:  that is the reference point for all others.  Note some VMs (like jview)

Anyway, I would actually like to change the jvmflags behavior a little more. The reason is
that the test harness is (and always has been, I guess) setting heap size flags for the server
JVM only if the jvmflags property is not null or the empty string:

    boolean setJvmFlags = false;
    if ( (jvmflags != null) && (jvmflags.length()>0) ) {
        setJvmFlags = true;

This means that if some JVM option other than -ms, -Xms, -mx or -Xmx is specified with the
jvmflags property, "harness-defaults" will be used for min (16 MB) and max size (32 MB). 
If jvmflags is not used, or empty, the harness will not set any heap size values. I do not
see the logic behind this, unless the jvmflags property is never used for any jvm flags other
than the heap flags mentioned above.

This behavior makes it impossible to accurately compare two test runs (in DerbyNet or DerbyNetClient
frameworks) with different jvm flags, as long as no heap size flags are set. Consider the
following example:

The lang/forupdate.sql test is chosen because there are no jvmflags associated with it by
default, and it can be run in embedded, DerbyNet and DerbyNetClient frameworks.

a) Default behavior:

Run the following command:

java -Dverbose=true -Dframework=DerbyNetClient org.apache.derbyTesting.functionTests.harness.RunTest

Let's say the default JVM for this machine is the Java HotSpot Client VM.
With the latest patch for this issue, the harness starts the network server by doing:

java -Duser.language=en -Duser.country=US -Dderby.system.home=/home/je159969/apache/Derby/sandBoxes/DERBY-1614/test/forupdate/DerbyNetClient/forupdate
-Djava.security.manager -Djava.security.policy=/home/je159969/apache/Derby/sandBoxes/DERBY-1614/test/forupdate/derby_tests.policy
-DderbyTesting.codedir=/home/je159969/apache/Derby/sandBoxes/DERBY-1614/trunk/jars/sane -DderbyTesting.serverhost=localhost
-DderbyTesting.clienthost=localhost -DderbyTesting.codeclasses=file://unused/ org.apache.derby.drda.NetworkServerControl

b) Run the test with some JVM option [1], for example -server (meaning: "Select the Java HotSpot
Server VM"):

java -Djvmflags=-server -Dverbose=true -Dframework=DerbyNetClient org.apache.derbyTesting.functionTests.harness.RunTest

With the latest patch for this issue, the harness starts the network server by doing:

java -Duser.language=en -Duser.country=US -server -ms16777216 -mx33554432 -Dderby.system.home=/home/je159969/apache/Derby/sandBoxes/DERBY-1614/test/forupdate/DerbyNetClient/forupdate
-Djava.security.manager -Djava.security.policy=/home/je159969/apache/Derby/sandBoxes/DERBY-1614/test/forupdate/derby_tests.policy
-DderbyTesting.codedir=/home/je159969/apache/Derby/sandBoxes/DERBY-1614/trunk/jars/sane -DderbyTesting.serverhost=localhost
-DderbyTesting.clienthost=localhost -DderbyTesting.codeclasses=file://unused/ org.apache.derby.drda.NetworkServerControl

The -server option is passed to the server JVM, but the harness also adds "-ms16777216 -mx33554432".
This means that tests may fail in b) that did not fail in a), or vice versa, but not because
of differences between the flags set in jvmflags, but because of the harness changing heap
size settings automatically. Note that this has always been the behavior of the test harness;
it is not caused by the above mentioned patch.


I propose that the harness either

A) stops setting any heap size flags for the network server, unless they are specified by
jvmflags. I.e. use the defaults of the JVM in which the server is run.


B) sets heap size flags for the network server every time neither of the flags -ms, -Xms,
-mx or -Xmx are specified in jvmflags, including when no jvmflags are specified.

I would like to see opinions from other community members before proceeding. 
If there is no reason why the harness should set server heap size by default, I vote for option

[1] All valid JVM options have the same effect, e.g. -d32, -d64, -Dderby.drda.logConnections=true
or -Demma.verbosity.level=silent

> Test harness overrides heap size settings when starting Network Server
> ----------------------------------------------------------------------
>                 Key: DERBY-1614
>                 URL: http://issues.apache.org/jira/browse/DERBY-1614
>             Project: Derby
>          Issue Type: Bug
>          Components: Test
>    Affects Versions:
>         Environment: Test frameworks DerbyNet and DerbyNetClient
>            Reporter: John H. Embretsen
>         Assigned To: John H. Embretsen
>             Fix For:
>         Attachments: DERBY-1614_v1.diff, DERBY-1614_v2.diff
> Test specific heap size settings can be passed to the test harness using the jvmflags
system property, for example in a <testname>_app.properties file or at the command line
when starting a test, e.g "-Djvmflags=-Xms32m^-Xmx32m".
> The test harness almost always overrides such settings when starting a new Network Server
using the org.apache.derbyTesting.functionTests.harness.NetServer class of the test harness.
Currently, if _either_ -ms _or_ -Xms is missing from the jvmflags, NetServer.start() adds
-ms16777216. Also, if _either_ -mx _or_ -Xmx is missing from the jvmflags, NetServer.start()
adds -ms33554432. This has been the case since SVN revision 420048 (July 8, 2006).
> Earlier revisions did not override the heap settings unless the newer -Xms or -Xmx flags
were used instead of the -ms and -mx flags. A patch for DERBY-1091 attempted (among other
things) to make the harness recognize the newer flags as well as the older flags, but the
resulting behavior is (most likely) not as intended. 
> If a test is run in either the DerbyNet framework or the DerbyNetClient framework, the
test-specific JVM flags should (probably) be used for the Network Server JVM as well as the
test JVM. Currently, even if non-default heap size flags are passed to the harness, the server
JVM will ignore these settings since the harness adds -ms and/or -mx flags _after_ all other
heap flags. The exception is if both new and old versions of heap flags are passed to the
harness, e.g:
> jvmflags=-ms32m^-Xms32m^-mx128m^-Xmx128m
> Here is the code causing this behaviour:
> if (setJvmFlags && ((jvmflags.indexOf("-ms") == -1) || (jvmflags.indexOf("-Xms")
== -1)))
>      // only setMs if no starting memory was given
>      jvm.setMs(16*1024*1024); // -ms16m
> if (setJvmFlags && ((jvmflags.indexOf("-mx") == -1) || (jvmflags.indexOf("-Xmx")
== -1)))
>      // only setMx if no max memory was given
>      jvm.setMx(32*1024*1024); // -mx32m

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


View raw message