[ http://issues.apache.org/jira/browse/DERBY-1614?page=all ]
John H. Embretsen updated DERBY-1614:
-------------------------------------
Attachment: DERBY-1614_v2.diff
(NEED ADVICE ON HOW TO PROCEED WITH RELATED HARNESS "DEFECT", SEE BELOW)
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) || (jvmName.equals("jview")))
./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) ) {
jvm.setFlags(jvmflags);
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 lang/forupdate.sql
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.codejar=file:/home/je159969/apache/Derby/sandBoxes/DERBY-1614/trunk/jars/sane/
-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 start
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 lang/forupdate.sql
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.codejar=file:/home/je159969/apache/Derby/sandBoxes/DERBY-1614/trunk/jars/sane/
-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 start
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.
NEW PROPOSAL:
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.
or
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 A).
[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: 10.2.0.0
> Environment: Test frameworks DerbyNet and DerbyNetClient
> Reporter: John H. Embretsen
> Assigned To: John H. Embretsen
> Fix For: 10.2.0.0
>
> 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
