[Fwd: Why does Hudson use -Dtest.maxHeapSize=256M]

[Ben Caradoc-Davies-2]

Hudson for GeoServer also uses -Dtest.maxHeapSize=256M, which is half
the default set in the main pom. Can we remove this option for
GeoServer? I expect major grief if we try to run app-schema unit tests
while this option is present.

The continuous integration engine should be consistent with the pom,
otherwise developers will run local tests, run their own CI, and commit
code which fails to build on Hudson.


-------- Original Message --------
Subject: Why does Hudson use  -Dtest.maxHeapSize=256M
Date: Thu, 09 Jul 2009 11:19:49 +0800
From: Ben Caradoc-Davies <Ben.Caradoc-Davies@...>
To: Justin Deoliveira <jdeolive@...>
CC: Geotools-Devel list <geotools-devel@...>
References: <4A555058.5070802@...> <4A555B9C.2060309@...>
<4A556007.1010207@...>

Ben Caradoc-Davies wrote:
> I can't figure out why app-schema fails to build on Hudson.

Justin, I think I found the problem:
http://hudson.opengeo.org/hudson/job/geotools-trunk/1792/consoleText

[gt_trunk] $ /opt/actual/apache-maven-2.1.0/bin/mvn -U clean install
-Djava.awt.headless=true -Dtest.maxHeapSize=256M -Dall

Why does Hudson use -Dtest.maxHeapSize=256M when the main pom sets this
to 512M?

Can we get rid of this option?

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@...>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia


--
Ben Caradoc-Davies <Ben.Caradoc-Davies@...>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@...
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Andrea Aime-4]

Ben Caradoc-Davies ha scritto:
> Hudson for GeoServer also uses -Dtest.maxHeapSize=256M, which is half
> the default set in the main pom. Can we remove this option for
> GeoServer? I expect major grief if we try to run app-schema unit tests
> while this option is present.

I think we added that option to avoid straining the build server, it
does not have _that_ many resources (it's a VM so it only gets a slice
of the real hardware).

I also find it a bit problematic that the thing requires so much memory.
Back then when  working with Windows I used to start GS with the default
heap (64MB) and reported any OOM that would occur as a bug.
But I know that other devs give it 256MB at the very least.

> The continuous integration engine should be consistent with the pom,
> otherwise developers will run local tests, run their own CI, and commit
> code which fails to build on Hudson.

Hmmm... let's make the default pom use 256MB then? ;-)

Seriously, we may look in having the build server use more memory for
some time (mind, this may well end up having the build server go in
a swap storm as a result) but I really feel a plan to avoid GS becoming
more of a memory hog should be on the table.

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@...
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Ben Caradoc-Davies-2]

Andrea Aime wrote:
> Hmmm... let's make the default pom use 256MB then? ;-)

That would be better than the current discrepancy.

> Seriously, we may look in having the build server use more memory for
> some time (mind, this may well end up having the build server go in
> a swap storm as a result) but I really feel a plan to avoid GS becoming
> more of a memory hog should be on the table.

Perhaps we make them both 512M for now and give us a few weeks to put
the app-schema unit tests on a diet? We have three options (not mutually
exclusive):

(1) Update EMF to a later, more efficient version.
(2) Gabriel's suggestion of not parsing absolutely everything.
(3) One-time test setup and read-only resource sharing between tests.

Between them, these should be able to remedy the bloat.

Kind regards,

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@...>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@...
https://lists.sourceforge.net/lists/listinfo/geoserver-devel