You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "John H. Embretsen (JIRA)" <de...@db.apache.org> on 2006/08/02 14:05:14 UTC

[jira] Updated: (DERBY-1614) Test harness overrides heap size settings when starting Network Server

     [ http://issues.apache.org/jira/browse/DERBY-1614?page=all ]

John H. Embretsen updated DERBY-1614:
-------------------------------------

    Attachment: DERBY-1614_v1.diff

Attatching patch 'DERBY-1614_v1.diff', which fixes the following issues:

   * harness/NetServer.java: Changes harness behaviour so that no heap settings for the Network Server are set if either initial or max heap size has already been set in the jvmflags argument of the NetServer constructor. Prior to this change, the harness would override heap size settings from the command line or test property files unless both old heap flags (-ms or -mx) AND "new" heap flags (-Xms or -Xmx) had been set. The harness would also treat initial and max sizes independently, which caused incompatibilities in some situations (see DERBY-1564). 
   * Behavior has *not* changed in scenarios where jvmflags (when passed to NetServer) is null or empty, in which case no extra flags are added.

   * testing/README.htm:
      * fixed small bug in jvmflags example (missing '-' in front of first flag).
      * changed jvmflags example from using -ms and -mx to using -Xms and -Xmx, since the latter flags are documented non-standard jvm options, while the former flags are deprecated (at least in Sun's current Java launchers...), and we are just lucky that they still work.
      * added comment about possible consequences of setting only initial or only max heap size using jvmflags.


svn stat:

M      java/testing/README.htm
M      java/testing/org/apache/derbyTesting/functionTests/harness/NetServer.java

The patch has been tested with individual test runs of lang/wisconsin.java and lang/forupdate.java. Derbyall is still running at the time of writing this...

Please review this patch.


Other patch comments:
------------------------------------------

- If only initial or only max heap size is set using the jvmflags harness property, no extra flags will be added by NetServer. This reduces the risk of incompatibilities between initial and max values, but it is still possible (which is also the case with any other Java application). For Sun's HotSpot JVM version 1.5, the default initial heap size is 2 MB, and the default max heap size is 64 MB [1]. Hence: 
   - if jvmflags specifies a max value that is smaller than 2 MB 
     (or whatever is the default for a particular JVM), without also 
     setting an initial heap size, or
   - if jvmflags specifies an initial value that is larger than the 
     default max heap size for a particular JVM (e.g. 64 MB),
     without also setting a max heap size,
   - the Java launcher will fail with the message like this:

> Error occurred during initialization of VM
> Incompatible initial and maximum heap sizes specified

- Current behavior depends on the JVM behavior described in DERBY-1091. Specifically, this means that as long as all test JVMs use the _last_ value of each heap setting if multiple values are specified, and old and new versions of heap flags are treated equally, we are all good.

- I was tempted to remove the following line in NetServer.java (but didn't):

     jvm.setNoasyncgc(true); // -noasyncgc

  since no JVM that I know of supports the -noasyncgc option anymore. The last HotSpot VM where that option was supported was supposedly version 1.1 [2]. Besides, I do not see any reason why we would want to turn of dynamic garbage collection for the server when running tests. Anyway, I'll let it be, since most jdk* classes in the harness ignore the setting anyway.


[1] http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/java.html and
      http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/java.html

[2] http://forums.java.net/jive/thread.jspa?threadID=16315&tstart=0


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