This one sort of has my name on it...
But I have some other fish to fry first - also, I have still 4 patches
outstanding and my environments are getting somewhat cluttered.

I'll try to have a look at this later today or tomorrow (PDT), unless
someone grabs it first.

Myrna

On 7/31/06, John H. Embretsen (JIRA) <[email protected]> wrote:
   [ 
http://issues.apache.org/jira/browse/DERBY-1614?page=comments#action_12424534 ]

John H. Embretsen commented on DERBY-1614:
------------------------------------------

Example impact of this bug:

The 'wisconsin_app.properties' file includes the following:

# flags specific to this test: it runs out of memory on jdk118 sometimes
# so give the JVM more memory always:
jvmflags=-ms32M^-mx128M

Running the lang/wisconsin.java test with default heap size results in the 
flags from the wisconsin_app.properties file being overridden by the test 
harness:

$ java -Dverbose=true -Dframework=DerbyNet 
org.apache.derbyTesting.functionTests.harness.RunTest lang/wisconsin.java

Output:

-- listing properties --
derby.debug.true=
derby.storage.checkpointInterval=100000
derby.optimizer.noTimeout=true
derby.language.preloadClasses=true
console.encoding:null file.encoding:ISO8859-1 derby.ui.codeset: null
*** Start: wisconsin jdk1.5.0_06 DerbyNet 2006-07-27 13:35:41 ***
Initialize for framework: DerbyNet
java -ms32M -mx128M -ms16777216 -mx33554432 [SNIP various system properties] 
org.apache.derby.drda.NetworkServerControl start
[SNIP rest of output]


The Network Server JVM pics up the last value for each heap setting (-ms and -Xms set the initial 
(minimum) heap size. -mx and -Xmx set the maximum heap size). This was (partly) verified by running 
the jmap tool (part of Sun's JDK 1.5 or newer) with the "-heap" option against the server 
JVM and looking for "MaxHeapSize", which was 32 MB, not 128 MB.

It is likely that during 10.2.0.4 snapshot testing (more precisely: All testing 
on trunk since July 8, 2006), tests using non-default heap size flags in 
DerbyNet or DerbyNetClient frameworks were run with different server heap sizes 
than previous testing.


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



Reply via email to