[ http://issues.apache.org/jira/browse/DERBY-1564?page=comments#action_12428614 ] John H. Embretsen commented on DERBY-1564: ------------------------------------------
Reply to Kathey's comment on Aug 10, 2006: --------------------------------------------------------------------------------- Seems to me that both the wisconsin test and stress.multi cause a lot of noise for testers and developers, but that this is something we have to accept, since every once in a while they may uncover a real product defect. But I think too few people know enough about these test to understand what they are supposed to do, what they really do, why we have these instabilities, and how to get rid of them. For example, compressing the tables in wisconsin helped fix DERBY-937 on most platforms with 10.2, but it seems that it is not exactly clear why it helped. Having more tests that are testing memory consumption directly (such as derbyStress.java) would be nice, I agree. Kathey wrote: ------------------------- "One thing I am not clear on is that it sounds like the test harness change (DERBY-1091) that causes this test to run with less memory was intentional, but should wisconsin be running with the lower memory configuration?" Short answer: ------------------------- Wisconsin should probably be running with at least 128 MB max heap size (which is the current setting). However, DERBY-1614 (which was partly and unintentionally caused by the fix for DERBY-1091) caused it to run with less memory (32 MB) for a while in trunk. Before the fix for DERBY-1091 was committed, the test was run with the jvm's defult heap size, which varies from platform to platform. This was not intentional either; it was intended to run with 128 MB max heap as specified in wisconsin_app.properties. Long answer: ------------------------- Well, I think one reason for all the confusion is that assumptions were made early on (about default heap sizes), that are no longer valid in general. Here's the comment from wisconsin_app.properties, which has been there since the test was contributed to Apache in 2004: # flags specific to this test: it runs out of memory on jdk118 sometimes # so give the JVM more memory always: jvmflags=-ms32M -mx128M (The format of the jvmflags has been changed in 10.2 and trunk. The values are still the same). This means that the default max heap size on jdk118 was considerably less than 128 MB, and that someone determined that the test needed this much memory to be able to run successfully. I don't know if this setting ever worked before the test and the harness was open-sourced, but it certainly does not work in 10.1, and it did not work in trunk/10.2 until the patch for DERBY-1614 was committed. Currently the default max heap size of most newer JVMs on reasonably new machines is equal to or larger than the setting that is specified for wisconsin. This means that wisconsin.java (trunk/10.2. since SVN rev 429550) on some platforms actually runs with a lower heap size than other tests. But that's no big deal - yet. That is also the reason why the patch for DERBY-1614 removed the harness code that set heap sizes for the Network Server by default. The harness default was a max heap size of 32 MB (the reasoning was that the Network Server needs more memory than the JVM's default), but that value was set a long time ago (as Myrna explained in a comment to DERBY-1614), and did not make sense anymore. I don't know if DERBY-1315 is related, since I don't know enough about what the wisconsin test actually does. > wisconsin.java test failed in DerbyNet or DerbyNetClient frameworks, VM for > network server got OutOfMemoryError > --------------------------------------------------------------------------------------------------------------- > > Key: DERBY-1564 > URL: http://issues.apache.org/jira/browse/DERBY-1564 > Project: Derby > Issue Type: Bug > Components: Network Server, Test, Regression Test Failure > Affects Versions: 10.2.0.0 > Environment: Solaris Sparc, Java 5 or 6, DerbyNet or DerbyNetClient > framework. > Reporter: Andreas Korneliussen > Fix For: 10.2.0.0 > > Attachments: port-wisconsin-from-10.2.0.4-to-10.1_v1.stat, > port-wisconsin-from-10.2.0.4-to-10.1_v1.zip, wisconsin.tar.gz > > > The wisconsin test failed on some Solaris (sparc) platforms during testing of > the 10.2.0.4 snapshot, in either the DerbyNet or DerbyNetClient framework. > No output in the outfile. On some platforms the DerbyNet.err file has one > message: > Exception in thread "Thread-2" java.lang.OutOfMemoryError: Java heap space > On some platforms the OutOfMemoryError is also (or instead) reported in the > derby.log file. > All test machines had 2 CPUs and 2 GB of RAM. > Here is a list of platforms where it failed: > Java 6 (Mustang, build 91) : > -------------------------------------------------- > Solaris 10 (sparc) > derbyall/derbynetmats/derbynetmats.fail:lang/wisconsin.java > Solaris 8 (sparcN-2) > derbyall/derbynetmats/derbynetmats.fail:lang/wisconsin.java > Solaris 10, local zone (sparc_zone1) > derbyall/derbynetmats/derbynetmats.fail:lang/wisconsin.java > Solaris 10, local zone (sparc_zone3) > derbynetclientmats/derbynetmats/derbynetmats.fail:lang/wisconsin.java > Solaris 10, global zone (zones) > derbynetmats/derbynetmats.fail:lang/wisconsin.java > Java 5 (Sun's HotSpot VM, v1.5.0): > --------------------------------------------------------------- > Solaris 9 (sparcN-1) > derbyall/derbynetclientmats/derbynetmats.fail:lang/wisconsin.java > Solaris 8 (sparcN-2) > derbyall/derbynetmats/derbynetmats.fail:lang/wisconsin.java > See http://www.nabble.com/10.2.0.4-Test-results-p5485739.html for details. -- 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
