[jboss-svn-commits] JBL Code SVN: r21517 - labs/jbosstm/trunk/qa.
jboss-svn-commits at lists.jboss.org
jboss-svn-commits at lists.jboss.org
Wed Aug 13 11:08:39 EDT 2008
Author: jhalliday
Date: 2008-08-13 11:08:39 -0400 (Wed, 13 Aug 2008)
New Revision: 21517
Modified:
labs/jbosstm/trunk/qa/run-dtf-local.xml
Log:
Explicitly set memory allocation for junit forked jvm. JBTM-390
Modified: labs/jbosstm/trunk/qa/run-dtf-local.xml
===================================================================
--- labs/jbosstm/trunk/qa/run-dtf-local.xml 2008-08-13 14:17:53 UTC (rev 21516)
+++ labs/jbosstm/trunk/qa/run-dtf-local.xml 2008-08-13 15:08:39 UTC (rev 21517)
@@ -82,8 +82,13 @@
<!-- this runs forked because the product config file it uses has relative paths in it, so we need to guarantee
- the working dir is the same as the location of this script. -->
- <junit printsummary="yes" haltonfailure="yes" fork="true" dir="${basedir}">
+ the working dir is the same as the location of this script.
+ TODO: investigate why it needs such a large memory footprint. I suspect it's buffering
+ the entire stdout, which is big for longer runs as DTF tends to be rather verbose.
+ But with 10MB of stdout based on text file size, junit needs >128MB of memory???
+ Stopping the buffering would be nice anyhow, as it stands we don't see any output in the file
+ until the tests are all done, which makes following progress a bit of a problem. -->
+ <junit printsummary="yes" haltonfailure="yes" fork="true" dir="${basedir}" maxmemory="192m">
<classpath>
<path refid="tests.classpath"/>
</classpath>
More information about the jboss-svn-commits
mailing list