[ 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
