db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manjula G Kutty <manjula.ku...@gmail.com>
Subject Re: LargeCodegen test fails with derbyclient while running largeData test suite
Date Wed, 03 May 2006 17:29:17 GMT
Ramandeep Kaur wrote:

> Hi,
>  
> I ran largeCodeGen as following:
>  java -Dverbose=true -Djvmflags="-mx512M -ms512M" 
> -Dframework=DerbyNetClient
> org.apache.derbyTesting.functionTests.harness.RunTest 
> lang/largeCodeGen.java
> With the above, I did NOT get usual error which was
> *** Start: largeCodeGen jdk1.4.2 largeDataTests:largeDataTests 
> 2006-04-29 08:30:04 ***
> 27a28
> > JVMST109: Insufficient space in Javaheap to satisfy allocation request
> Test Failed.
> *** End:   largeCodeGen jdk1.4.2 largeDataTests:largeDataTests 
> 2006-04-29 08:32:01 ***
>  
> Instead, I got another error which is
> < PASS: IN clause with 97000 parameters
> 20 del
> < PASS: PREPARE: IN clause with 98000 parameters
> 21 del
> < PASS: IN clause with 98000 parameters
> 22 del
> < FAILED QUERY: IN clause with 99000 parameters.
> 22a19
> > FAILED QUERY: IN clause with 97000 parameters.
> Test Failed.
>  
> Here are the contents of test.txt
>
> *** Start: largeCodeGen jdk1.4.2 DerbyNetClient 2006-05-02 17:06:24 ***
> Initialize for framework: DerbyNetClient
> java -mx512M -ms512M 
> -Dderby.system.home=/local0/NightlyBuildResults.2006-05-02/
> ibm142_largeDataTests/DerbyNetClient/largeCodeGen - 
> Djava.security.manager -Djava
> .security.policy=/local0/NightlyBuildResults.2006-05-02/ibm142_largeDataTests/de
> rby_tests.policy 
> -DderbyTesting.codejar=file:/local1/cloudtst/dev/src/jars/insan
> e/ -DderbyTesting.codedir=/local1/cloudtst/dev/src/jars/insane 
> -DderbyTesting.se
> rverhost=localhost -DderbyTesting.clienthost=localhost 
> -DderbyTesting.codeclasse
> s=file://unused/ org.apache.derby.drda.NetworkServerControl start
> Attempt to shutdown framework: DerbyNetClient
> 19 del
> < PASS: IN clause with 97000 parameters
> 20 del
> < PASS: PREPARE: IN clause with 98000 parameters
> 21 del
> < PASS: IN clause with 98000 parameters
> 22 del
> < FAILED QUERY: IN clause with 99000 parameters.
> 22a19
> > FAILED QUERY: IN clause with 97000 parameters.
> Test Failed.
> *** End:   largeCodeGen jdk1.4.2 DerbyNetClient 2006-05-02 17:08:07 ***
>  
> Now it looks like it could be a diff problem. Any idea???
>  
> Thanks, Raman
>
>  
> On 2/27/06, *John Embretsen* <John.Embretsen@sun.com 
> <mailto:John.Embretsen@sun.com>> wrote:
>
>     Kathey Marsden wrote:
>
>     > Manjula G Kutty wrote:
>     >
>     >> I have closed all the statements, prepared statements and
>     resultsets
>     >> in the largeCodeGen.java file. But still the test passes with
>     embedded
>     >> but fails with derbyClient. I'm attaching the modified
>     >> largeCodeGen.java file
>     >>
>     > Hi Manjula,
>     >
>     > Because this test throws a lot of exceptions, the statements and
>     > prepared statements would need to be closed in a finally
>     block.     But
>     > I just noticed something that might be causing this and it is
>     related to
>     > the test harness.
>     > When we run the test network server starts and gets the jvmFlags
>     > specified for the test in largeCodeGen_app.properties
>     > jvmflags=-Xmx512M -Xms512M
>     > (Whether that is at all right I don't know since app_properties
>     is I
>     > think supposed to be for the client).
>     >
>     > But it also gets these conflicting properties (from the harness
>     itself?)
>     > -ms16777216 -mx33554432
>     >
>     > So which is the server really using?
>
>     The server is using the latter (-ms16777216 -mx33554432), since these
>     override the flags passed from the largeCodeGen_app.properties file. I
>     verified this by running the lang/largeCodeGen.java test from
>     current trunk
>     with Sun JDK 1.5 and -Dframework=DerbyNetClient.
>
>     By the way, in my environment the above test run hangs (using
>     DerbyNetClient). I have not investigated this further, but the
>     heap does look
>     full.
>
>     I used the jinfo and jmap tools that come with the JDK to observe
>     the flags
>     received by the server JVM and the actual heap configuration used
>     by the
>     server while running the test (I got the VMIDs using the jps tool).
>
>     By running "jinfo -flags" I got (extract):
>
>     VM Flags:
>     -Xmx512M -Xms512M -Xms16777216 -Xmx33554432
>     -Dderby.system.home=/home/je159969/apache/Derby/clean/tests/largeCodeGen2/DerbyNetClient/largeCodeGen
>
>     -Djava.security.manager
>     -Djava.security.policy=/home/je159969/apache/Derby/clean/tests/largeCodeGen2/derby_tests.policy
>
>
>     -DderbyTesting.codejar=file:/home/je159969/apache/Derby/clean/trunk/jars/sane/
>     -DderbyTesting.codedir=/home/je159969/apache/Derby/clean/trunk/jars/sane
>     -DderbyTesting.serverhost=localhost
>     -DderbyTesting.clienthost=localhost
>     -DderbyTesting.codeclasses=file://unused/
>
>     By running "jmap -heap" I got (extract):
>
>     Heap Configuration:
>        MinHeapFreeRatio = 40
>        MaxHeapFreeRatio = 70
>        MaxHeapSize      = 33554432 ( 32.0MB)
>        NewSize          = 655360 (0.625MB)
>        MaxNewSize       = 4294901760 (4095.9375MB)
>        OldSize          = 1441792 (1.375MB)
>        NewRatio         = 12
>        SurvivorRatio    = 32
>        PermSize         = 8388608 ( 8.0MB)
>        MaxPermSize      = 67108864 (64.0MB)
>
>
>     I.e., jmap reports the max heap size as 32 MB, not 512 MB.
>
>     The extra (overriding) jvm heap size flags are set in
>     NetServer.java in the
>     harness package, which is used by RunTest.java (line 286) to start the
>     network server. This code seems to be old (and buggy), since it
>     looks for flags
>     starting with "-ms" or "-mx", not "-Xms" or "-Xmx". Here's the
>     code that is
>     producing the flags:
>
>     if (!jvmName.equals("jview"))
>     {
>         if (setJvmFlags && (jvmflags.indexOf("-ms") == -1))
>         // only setMs if no starting memory was given
>         jvm.setMs (16*1024*1024); // -ms16m
>         if (setJvmFlags && (jvmflags.indexOf("-mx") == -1))
>         // only setMx if no max memory was given
>         jvm.setMx(32*1024*1024); // -mx32m
>         jvm.setNoasyncgc(true); // -noasyncgc
>     }
>
>     The class level comment in jvm.java lists the "valid" jvm options,
>     supposedly
>     from "java -help". This list does not look anything like the
>     option lists I
>     get from Sun's JDKs 1.3 through 1.6, so I guess it is a few years
>     old...
>
>
>     --
>     John
>
>
>
>
>
>
>
>
> -- 
> Ramandeep Kaur
> ramandhindsa@gmail.com <mailto:ramandhindsa@gmail.com> 

Hi Raman,

I would suggest you to run the entire suite (largedata) and then get the 
diff for both embedded and DerbynetClient. That way we can know whether 
it is a mere master update or a problem. Please let me know the result 
after running the entire suite

Thanks
Manjula

Mime
View raw message