-
Bug
-
Resolution: Unresolved
-
Critical
-
None
-
Solaris 10,Glassfish v2, hudson 1.336,maven 2.2.1
machine: SunOS hostname 5.10 Generic_137111-08 sun4u sparc SUNW,Sun-Fire-V490
I have a large project which I am trying to build a site for. In order to have hudson collect unittest,checkstyle,findbugs etc. trends. However there appears to be a critical performance difference between running the site as a maven2 job and as a freestyle job.
My build looks like this:
- 1 parent reactor pom
- 57 modules in a mix of jar,war,ear and a assembly zip module
- Some of these modules have unittest
- Some of these modules contains antrun tasks needed for webservice (server and client),weblogic mbean,weblogic workshop frontend. most of these antruns are wrapped in a "if" task to avoid needless regenerations (like javac skipping compile of class files are up2date)
I think the problem comes from the large number to "install" lifecycles the report cycles starts in order to be sure the unitests has been run.
Here are the performance I am seeing running site on this job
- manual maven on my laptop (Lenovo Thinkpad T61P 2.4 ghz) 30-40 minutes
- hudson freestyle project: 90 minutes
- hudson maven2 job (1. attempt): build failed after 11 hours, most likely because og missing dependency (most likely another job was deploying in nexus repo)
- hudson maven2 job (2. attempt): build appears to be hanging and was killed after 17 hours, the build appear to be approx halfway.
To give an idea of the general performance, a normal install runs like this:
- laptop: 4-5 minutes
- hudson maven2 job: 15 minutes
So in normal install the build server takes approx 3 times as long. and during site this differece is the same for freestyle projects, but maven2 projects seem take forever.
When the build seems to be taking forever, please go to the build page on Hudson, then click "monitor Maven process", and grab the thread dump of the Maven process and attach it here. If you can, do it several times with some time apart so that we can have multiple samples.
Also, look at the console output as it appears, and show us where a long delay occurs. That helps us find where the problem is.
Finally, do you do distributed builds? If so, tell us how you connect your master and slave, and if it has enough bandwidth.