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/07/31 15:20:14 UTC

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

    [ 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

        

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

Posted by "John H. Embretsen" <Jo...@Sun.COM>.
Myrna van Lunteren wrote:

> In the mean time, I had to reopen DERBY-1091 & there's a follow-up
> patch, maybe you can check that that doesn't conflict with your
> proposed patch?

Yes, there is no potential patch conflict. You touch the RunSuite class 
only, while my patch will include modifications to the NetServer class 
only (as it looks today).

Actually, my current patch only changes two ORs (||) to ANDs (&&). But I 
am thinking of adding some more checks to avoid potential conflicts 
between initial and max heap settings. And I have to run some tests, of 
course...  :)


-- 
John


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

Posted by Myrna van Lunteren <m....@gmail.com>.
On 7/31/06, John Embretsen <Jo...@sun.com> wrote:
> Myrna van Lunteren wrote:
> > 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.
>
> No problem, Myrna, I already have a patch for it in my sandbox, so I'll
> handle this particular issue (I have assigned myself). There are some
> subtleties that I wanted to think more about before submitting the
> patch, but I'll certainly do so tomorrow or later this week.
>
> --
> John
>
Cool! I'll look forward to seeing your patch.
In the mean time, I had to reopen DERBY-1091 & there's a follow-up
patch, maybe you can check that that doesn't conflict with your
proposed patch?
Myrna

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

Posted by John Embretsen <Jo...@Sun.COM>.
Myrna van Lunteren wrote:
> 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.

No problem, Myrna, I already have a patch for it in my sandbox, so I'll 
handle this particular issue (I have assigned myself). There are some 
subtleties that I wanted to think more about before submitting the 
patch, but I'll certainly do so tomorrow or later this week.

-- 
John

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

Posted by Myrna van Lunteren <m....@gmail.com>.
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) <de...@db.apache.org> 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
>
>
>