db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John H. Embretsen (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1564) wisconsin.java test failed in DerbyNet or DerbyNetClient frameworks, VM for network server got OutOfMemoryError
Date Thu, 17 Aug 2006 09:47:14 GMT
    [ 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

        

Mime
View raw message