[Geoserver-devel] [Why does Hudson use -Dtest.maxHeapSize=256M]

Ben_Caradoc-Davies · July 9, 2009, 3:35am

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@anonymised.com>
To: Justin Deoliveira <jdeolive@anonymised.com>
CC: Geotools-Devel list <geotools-devel@lists.sourceforge.net>
References: <4A555058.5070802@anonymised.com> <4A555B9C.2060309@anonymised.com> <4A556007.1010207@anonymised.com>

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@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

Andrea_Aime3 · July 9, 2009, 6:03am

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.

Ben_Caradoc-Davies · July 9, 2009, 6:23am

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@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia