You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Russell E Glaue <rg...@cait.org> on 2011/06/22 18:09:05 UTC
Speeding up G3.0 build time
I am wanting to update the G3 dev wiki to help first-time builders get started.
How would you suggest a build of G3 could become faster?
The only tip I am aware of for speeding up trunk (G3) builds is to install a
maven repository proxy like nexus. This is eluded to in the wiki already.
Are there any other tips?
I have been able to successfully build G3 from trunk several times now but with
differing build time results.
The best build time I have had is 13 hours.
The worst build time I have had is 39 hours. (this is from my latest build)
I am using a very basic build procedure.
1. checkout G3 trunk
2. JAVA_HOME="/path/to/jdk/1.6.0_22"
3. download and install a fresh maven 2.2.1
4. MAVEN_OPTS="-Xmx968m -XX:MaxPermSize=500m -XX:ReservedCodeCacheSize=64m"
5. mvn clean install
6. 13 to 39 hours later == BUILD SUCCESS
>From observing the build process, it would seem the most used (seemingly paused)
time is right before the build process moves on to the next plugin or assembly.
This "seemingly paused time" after the assembly I assume is the packaging
process, because the resulting output is a huge collection.
[INFO] Geronimo Assemblies ............................... SUCCESS [3.995s]
[INFO] Geronimo Assemblies :: Minimal + Jetty8 ........... SUCCESS [8:15.210s]
[INFO] Geronimo Assemblies :: Java EE 6 Web Profile + Jetty8 SUCCESS [1:57:17.311s]
[INFO] Geronimo Assemblies :: Java EE 6 + Jetty8 ......... SUCCESS [1:02:47.374s]
[INFO] Geronimo Assemblies :: Minimal + Tomcat7 .......... SUCCESS [8:08.838s]
[INFO] Geronimo Assemblies :: Java EE 6 Web Profile + Tomcat7 SUCCESS
[1:59:16.619s]
[INFO] Geronimo Assemblies :: Java EE 6 + Tomcat7 ........ SUCCESS [1:08:13.854s]
That is ~1.5 hours for the "Java EE 6 Web Profile + Jetty8" and "Java EE 6 Web
Profile + Tomcat7" assemblies.
For the plugins, I would assume the same, except that I notice that, of course,
the latest snapshot dependencies are being downloaded, and the poms in the maven
SNAPSHOT repositories are continually being accessed.
I realize that because trunk (G3) largely depends on 3rd-party artifact
SNAPSHOTS that these repositories are checked during every build, and new
SNAPSHOT libraries are always being downloaded (as is the nature of snapshot
releases).
As it is not a simple process for a user to setup a maven repo proxy, and could
be a deterrent to someone getting started if it were necessary to install a
proxy, I am looking at other methods and tips that might increase the speed of
building G3.
Is this feasible? Or would we just say, that because of the nature of SNAPSHOT
builds and their dependencies on 3rd-party SNAPSHOT artifacts, there is no real
means to improving build speed unless a proxy is utilized?
If the later is true, I would like to add this note in the wiki's build
documentation. And also warn those who choose to build without a proxy may
experience a long build time.
Discussion?
-RG
Re: Speeding up G3.0 build time
Posted by chi runhua <ch...@gmail.com>.
On Fri, Jun 24, 2011 at 6:09 AM, David Jencks <da...@yahoo.com>wrote:
> Hi Russell,
>
> I for one really appreciate you putting in the time and effort on these
> docs. It's all too easy to think that since it works for me it will work
> the same for others and not document what is actually needed.
>
> thanks!
> david jencks
>
> On Jun 23, 2011, at 2:35 PM, Russell E Glaue wrote:
>
> >
> >
> > On 06/23/2011 12:06 PM, Russell E Glaue wrote:
> >> On 06/22/2011 04:49 PM, David Jencks wrote:
> >>> I've had disk thrashing up my build times from ~30 min to ~2 hours, but
> never this much. I have no evidence but would suspect a DNS problem
> resulting in multiple DNS timeouts for each module.
> >>>
> >>> Do you have a more-memory-endowed machine on this network you could try
> a build on to see if it's faster?
> >>>
> >>> thanks
> >>> david jencks
> >>
> >> I got another server in our lab, and put 2GB of memory in it. It has a
> single
> >> 2.4GHz dual-core CPU. I'll run a build on it, and we can compare.
> >> -RG
> >
> > I ran the build with an empty maven repository on the machine spec'ed
> above.
> > The results are:
> > [INFO]
> ------------------------------------------------------------------------
> > [INFO] BUILD SUCCESSFUL
> > [INFO]
> ------------------------------------------------------------------------
> > [INFO] Total time: 94 minutes 7 seconds
> > [INFO] Finished at: Thu Jun 23 16:40:50 EDT 2011
> > [INFO] Final Memory: 626M/935M
> > [INFO]
> ------------------------------------------------------------------------
> >
> > Much better!
> >
> > I updated the wiki docs with this spec as the suggest minimal
> configuration of a
> > build machine, reflected the build times, and compared it with the 1GB
> build
> > machine configuration I tested and reported earlier.
> >
> >
> > Thanks for everyone help and tips!
> > The GMOxDEV build docs are all up to date now, and hopefully useful
> enough to
> > answer most questions about building G3.0.
> >
> > -RG
>
>
Thanks for your effort, it looks much better now~!
Jeff
Re: Speeding up G3.0 build time
Posted by David Jencks <da...@yahoo.com>.
Hi Russell,
I for one really appreciate you putting in the time and effort on these docs. It's all too easy to think that since it works for me it will work the same for others and not document what is actually needed.
thanks!
david jencks
On Jun 23, 2011, at 2:35 PM, Russell E Glaue wrote:
>
>
> On 06/23/2011 12:06 PM, Russell E Glaue wrote:
>> On 06/22/2011 04:49 PM, David Jencks wrote:
>>> I've had disk thrashing up my build times from ~30 min to ~2 hours, but never this much. I have no evidence but would suspect a DNS problem resulting in multiple DNS timeouts for each module.
>>>
>>> Do you have a more-memory-endowed machine on this network you could try a build on to see if it's faster?
>>>
>>> thanks
>>> david jencks
>>
>> I got another server in our lab, and put 2GB of memory in it. It has a single
>> 2.4GHz dual-core CPU. I'll run a build on it, and we can compare.
>> -RG
>
> I ran the build with an empty maven repository on the machine spec'ed above.
> The results are:
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD SUCCESSFUL
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 94 minutes 7 seconds
> [INFO] Finished at: Thu Jun 23 16:40:50 EDT 2011
> [INFO] Final Memory: 626M/935M
> [INFO] ------------------------------------------------------------------------
>
> Much better!
>
> I updated the wiki docs with this spec as the suggest minimal configuration of a
> build machine, reflected the build times, and compared it with the 1GB build
> machine configuration I tested and reported earlier.
>
>
> Thanks for everyone help and tips!
> The GMOxDEV build docs are all up to date now, and hopefully useful enough to
> answer most questions about building G3.0.
>
> -RG
Re: Speeding up G3.0 build time
Posted by Russell E Glaue <rg...@cait.org>.
On 06/23/2011 12:06 PM, Russell E Glaue wrote:
> On 06/22/2011 04:49 PM, David Jencks wrote:
>> I've had disk thrashing up my build times from ~30 min to ~2 hours, but never this much. I have no evidence but would suspect a DNS problem resulting in multiple DNS timeouts for each module.
>>
>> Do you have a more-memory-endowed machine on this network you could try a build on to see if it's faster?
>>
>> thanks
>> david jencks
>
> I got another server in our lab, and put 2GB of memory in it. It has a single
> 2.4GHz dual-core CPU. I'll run a build on it, and we can compare.
> -RG
I ran the build with an empty maven repository on the machine spec'ed above.
The results are:
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 94 minutes 7 seconds
[INFO] Finished at: Thu Jun 23 16:40:50 EDT 2011
[INFO] Final Memory: 626M/935M
[INFO] ------------------------------------------------------------------------
Much better!
I updated the wiki docs with this spec as the suggest minimal configuration of a
build machine, reflected the build times, and compared it with the 1GB build
machine configuration I tested and reported earlier.
Thanks for everyone help and tips!
The GMOxDEV build docs are all up to date now, and hopefully useful enough to
answer most questions about building G3.0.
-RG
Re: Speeding up G3.0 build time
Posted by Russell E Glaue <rg...@cait.org>.
On 06/22/2011 04:49 PM, David Jencks wrote:
> I've had disk thrashing up my build times from ~30 min to ~2 hours, but never this much. I have no evidence but would suspect a DNS problem resulting in multiple DNS timeouts for each module.
>
> Do you have a more-memory-endowed machine on this network you could try a build on to see if it's faster?
>
> thanks
> david jencks
I got another server in our lab, and put 2GB of memory in it. It has a single
2.4GHz dual-core CPU. I'll run a build on it, and we can compare.
-RG
>
> On Jun 22, 2011, at 1:32 PM, Russell E Glaue wrote:
>
>> On 06/22/2011 01:54 PM, Kevan Miller wrote:
>>>
>>> On Jun 22, 2011, at 1:27 PM, Russell E Glaue wrote:
>>>
>>>> On 06/22/2011 12:02 PM, Kevan Miller wrote:
>>>>>
>>>>> On Jun 22, 2011, at 12:09 PM, Russell E Glaue wrote:
>>>
>>> <snip>
>>>
>>>>>
>>>>>>
>>>>>> I am using a very basic build procedure.
>>>>>> 1. checkout G3 trunk
>>>>>> 2. JAVA_HOME="/path/to/jdk/1.6.0_22"
>>>>>> 3. download and install a fresh maven 2.2.1
>>>>>> 4. MAVEN_OPTS="-Xmx968m -XX:MaxPermSize=500m -XX:ReservedCodeCacheSize=64m"
>>>>>
>>>>> My settings are similar. I don't specify '-XX:ReservedCodeCacheSize=64m'.
>>>>>
>>>>> I run with the following. I know there are others running with larger max heaps. I haven't :
>>>>>
>>>>> MAVEN_OPTS="-Xmx1024m -XX:MaxPermSize=512m -XX:+HeapDumpOnOutOfMemoryError"
>>
>> Without the "-XX:ReservedCodeCacheSize=64m" option in MAVEN_OPTS I get this
>> OutOfMemory error:
>> -
>> [INFO] ------------------------------------------------------------------------
>> [INFO] Building Geronimo Build Support :: Plugin 3.0-SNAPSHOT
>> [INFO] ------------------------------------------------------------------------
>> ...<snip>...
>> [INFO] --- maven-compiler-plugin:2.0.2:compile (default-compile) @
>> buildsupport-maven-plugin ---
>> [INFO] Compiling 3 source files to
>> /data/geronimo/asf-geronimo-server-trunk/framework/buildsupport/buildsupport-maven-plugin/target/classes
>> [INFO]
>> [INFO] --- gmaven-plugin:1.2:compile (default) @ buildsupport-maven-plugin ---
>> ---------------------------------------------------
>> constituent[0]: file:/usr/local/apache-maven-3.0.3/lib/maven-embedder-3.0.3.jar
>> ...<snip>...
>> constituent[30]: file:/usr/local/apache-maven-3.0.3/lib/maven-compat-3.0.3.jar
>> ---------------------------------------------------
>> Exception in thread "main" java.lang.VirtualMachineError: out of space in
>> CodeCache for adapters
>> at
>> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:212)
>> at
>> org.codehaus.groovy.ast.builder.AstBuilderTransformation.visit(AstBuilderTransformation.groovy:62)
>> at
>> org.codehaus.groovy.transform.ASTTransformationVisitor$3.call(ASTTransformationVisitor.java:268)
>> at
>> org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:799)
>> at
>> org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:464)
>> at
>> org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:443)
>> at
>> org.codehaus.gmaven.runtime.v1_6.ClassCompilerFeature$ClassCompilerImpl.compile(ClassCompilerFeature.java:159)
>> at
>> org.codehaus.gmaven.plugin.compile.AbstractCompileMojo.compile(AbstractCompileMojo.java:200)
>> at
>> org.codehaus.gmaven.plugin.compile.AbstractCompileMojo.process(AbstractCompileMojo.java:164)
>> at
>> org.codehaus.gmaven.plugin.ComponentMojoSupport.doExecute(ComponentMojoSupport.java:60)
>> at org.codehaus.gmaven.plugin.MojoSupport.execute(MojoSupport.java:69)
>> at
>> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
>> at
>> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
>> at
>> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
>> -
>>
>> With the "-XX:ReservedCodeCacheSize=64m" flag, I do not get this error.
>>
>>
>>>>
>>>> The server I am build on has 1024MB of memory total, and has a dual dual-core
>>>> Intel(R) XEON(TM) CPU 2.00GHz with 512KB cache.
>>>>
>>>> I have tried many JVM configurations, and the one like mine and yours is the
>>>> best one I have found. For me, a JVM configuration with less than 400m for
>>>> MaxPermSize always ended with an OutOfMemory error on PermGen space.
>>>>
>>>> The Geronimo dev wiki suggests 200m for MaxPermSize, which never worked for me
>>>> for trunk. I always assumed it was because of all the snapshot downloading the
>>>> build process has to do. Even after the 2nd or 3rd build, 200m was never enough.
>>>
>>> Right. So, MaxPermSize=200m is definitely out-of-date. There is/may be some bugs that are increasing this value. However, not really worth our while to pursue at the moment. I don't think MaxPermSize=500m is too prohibitive. More important things to do, ATM.
>>>
>>> That said -- I'm building on a machine with 8 gigs of real memory. So, 1024MB of real memory seems very small to me. And I suspect that this is the source of your problem... A max heap of 1024MB and MaxPermSize of 512m means your system may be spending a lot of time swapping virtual memory.
>>
>> So wrote what are your JVM Options set at:
>> MAVEN_OPTS="-Xmx1024m -XX:MaxPermSize=512m -XX:+HeapDumpOnOutOfMemoryError"
>> Mine are:
>> MAVEN_OPTS="-Xmx968m -XX:MaxPermSize=500m -XX:ReservedCodeCacheSize=64m"
>>
>> The machine I am using has 1024MB of real memory and is dedicated to building
>> geronimo (and it is not a virtual server). I set the heap max to 968m to keep
>> the memory usage from peaking at 100% of system capacity.
>>
>> But there is a chance you may be right about the swaping. the machine runs at
>> 100% real memory usage (expected) and about ~50% swap.
>>
>>
>> I thinking recommending a minimum amount of real memory a machine should have to
>> adequately compile G3 in a reasonable amount of time should be suggested.
>> What would you say the minimum recommendation should be? For Windows and Linux?
>> 2GB for Windows and 1.5GB for Linux, assuming the machine is dedicated to compiling?
>>
>>>
>>>>
>>>>>
>>>>>> 5. mvn clean install
>>>>>> 6. 13 to 39 hours later == BUILD SUCCESS
>>>>>>
>>>>>>
>>>>>> From observing the build process, it would seem the most used (seemingly paused)
>>>>>> time is right before the build process moves on to the next plugin or assembly.
>>>>>>
>>>>>> This "seemingly paused time" after the assembly I assume is the packaging
>>>>>> process, because the resulting output is a huge collection.
>>>>>>
>>>>>> [INFO] Geronimo Assemblies ............................... SUCCESS [3.995s]
>>>>>> [INFO] Geronimo Assemblies :: Minimal + Jetty8 ........... SUCCESS [8:15.210s]
>>>>>> [INFO] Geronimo Assemblies :: Java EE 6 Web Profile + Jetty8 SUCCESS [1:57:17.311s]
>>>>>> [INFO] Geronimo Assemblies :: Java EE 6 + Jetty8 ......... SUCCESS [1:02:47.374s]
>>>>>> [INFO] Geronimo Assemblies :: Minimal + Tomcat7 .......... SUCCESS [8:08.838s]
>>>>>> [INFO] Geronimo Assemblies :: Java EE 6 Web Profile + Tomcat7 SUCCESS
>>>>>> [1:59:16.619s]
>>>>>> [INFO] Geronimo Assemblies :: Java EE 6 + Tomcat7 ........ SUCCESS [1:08:13.854s]
>>>>>>
>>>>>> That is ~1.5 hours for the "Java EE 6 Web Profile + Jetty8" and "Java EE 6 Web
>>>>>> Profile + Tomcat7" assemblies.
>>>>>
>>>>> Here are my build times. This is running without tests. Which would affect the overall build time. Assembly times would be unaffected -- we don't run any tests when building assemblies.
>>>>>
>>>>> [INFO] Geronimo Assemblies ............................... SUCCESS [0.163s]
>>>>> [INFO] Geronimo Assemblies :: Minimal + Jetty8 ........... SUCCESS [42.253s]
>>>>> [INFO] Geronimo Assemblies :: Java EE 6 Web Profile + Jetty8 SUCCESS [1:04.295s]
>>>>> [INFO] Geronimo Assemblies :: Java EE 6 + Jetty8 ......... SUCCESS [1:33.097s]
>>>>> [INFO] Geronimo Assemblies :: Minimal + Tomcat7 .......... SUCCESS [41.587s]
>>>>> [INFO] Geronimo Assemblies :: Java EE 6 Web Profile + Tomcat7 SUCCESS [1:14.409s]
>>>>> [INFO] Geronimo Assemblies :: Java EE 6 + Tomcat7 ........ SUCCESS [1:46.333s]
>>>>> [INFO] ------------------------------------------------------------------------
>>>>> [INFO] BUILD SUCCESS
>>>>> [INFO] ------------------------------------------------------------------------
>>>>> [INFO] Total time: 28:15.199s
>>>>> [INFO] Finished at: Wed Jun 22 12:38:10 EDT 2011
>>>>> [INFO] Final Memory: 633M/1011M
>>>>> [INFO] ------------------------------------------------------------------------
>>>>
>>>> Yours is about 1/3 faster than mine.
>>>
>>> I think you've missed the metric. My times are an order of magnitude (hours vs minutes) better than yours.
>>>
>>>>>> [INFO] Geronimo Assemblies :: Java EE 6 + Tomcat7 ........ SUCCESS [1:08:13.854s]
>>>
>>> and
>>>
>>>>> [INFO] Geronimo Assemblies :: Java EE 6 + Tomcat7 ........ SUCCESS [1:46.333s]
>>>
>>> That's 68 minutes vs 1 minute 46 seconds. My *total* build time was 28 minutes.
>>
>> Oh. ya. Let me rub my eyes and take another look there.... your right!
>>
>>>
>>>> But you might have a faster processor too.
>>>> Obviously, this part of the build is not the time consumer for me. It is nice to
>>>> know this part of the build is supposed to take several hours - that helps me
>>>> narrow down the issues.
>>
>> Okay - this was an incorrect statement by me.
>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> For the plugins, I would assume the same, except that I notice that, of course,
>>>>>> the latest snapshot dependencies are being downloaded, and the poms in the maven
>>>>>> SNAPSHOT repositories are continually being accessed.
>>>>>>
>>>>>> I realize that because trunk (G3) largely depends on 3rd-party artifact
>>>>>> SNAPSHOTS that these repositories are checked during every build, and new
>>>>>> SNAPSHOT libraries are always being downloaded (as is the nature of snapshot
>>>>>> releases).
>>>>>
>>>>> Correct. A local maven proxy (e.g. Nexus) can reduce the overhead.
>>>>
>>>> So it is worth noting as it already is now.
>>>>
>>>>>
>>>>>>
>>>>>> As it is not a simple process for a user to setup a maven repo proxy, and could
>>>>>> be a deterrent to someone getting started if it were necessary to install a
>>>>>> proxy, I am looking at other methods and tips that might increase the speed of
>>>>>> building G3.
>>>>>
>>>>> I've tried running with a local maven proxy. However, I've found it to be too much trouble to maintain/configure.
>>>>
>>>> Agreed. At least it is too much trouble if you are not continuously building the
>>>> entire trunk every day on the larger scale. So too much to ask a G3 beginner to do.
>>>
>>> Too much to ask of a new maven user -- I agree.
>>>
>>>>
>>>>>
>>>>>>
>>>>>> Is this feasible? Or would we just say, that because of the nature of SNAPSHOT
>>>>>> builds and their dependencies on 3rd-party SNAPSHOT artifacts, there is no real
>>>>>> means to improving build speed unless a proxy is utilized?
>>>>>> If the later is true, I would like to add this note in the wiki's build
>>>>>> documentation. And also warn those who choose to build without a proxy may
>>>>>> experience a long build time.
>>>>>
>>>>> While I'm thinking about it -- what is your network environment? The focus on proxies imply that your slow build times are predominantly network issue. Are you certain that is the case?
>>>>
>>>> We have about ~14Mb/s speed to the Internet. Our backplane is Gigabit Ethernet.
>>>> We are connected to a major Internet backbone provider.
>>>> I have been wondering if the problem is responsiveness of the maven repo sites.
>>>> I have been seeing on occasion a refusal to download an artifact from the site,
>>>> where as I was able to download it within a browser from the same URL.
>>>> So I wonder if the repo sites are either metering the usage on a per user or
>>>> session basis.
>>>
>>> I'm building on my home broadband connection. Probably similar speeds. I think we should identify the source of your extremely slow build time.
>>>
>>> If remote repository lookups are the cause of your problems, 'mvn -o clean install' should result in a much faster build time. However, I suspect that it won't make much difference at all...
>>
>> It seems a lot of "pauses" in the build process (while using the
>> '-DskipTests=true' flag) is at the end of building each plugin, and that looks
>> like this (example plugin build output)...
>> (Note: almost every plugin gives the log4j errors)
>> -
>> [INFO] ------------------------------------------------------------------------
>> [INFO] Building Geronimo Plugins, Corba :: Deployer 3.0-SNAPSHOT
>> [INFO] ------------------------------------------------------------------------
>> [INFO]
>> [INFO] --- maven-clean-plugin:2.3:clean (default-clean) @ openejb-corba-deployer ---
>> [INFO]
>> [INFO] --- genesis-maven-plugin:2.0:validate-configuration (default) @
>> openejb-corba-deployer ---
>> [INFO]
>> [INFO] --- geronimo-property-plugin:3.0-SNAPSHOT:set-property (set-property) @
>> openejb-corba-deployer ---
>> [INFO]
>> [INFO] --- maven-enforcer-plugin:1.0-beta-1:enforce (default) @
>> openejb-corba-deployer ---
>> [INFO]
>> [INFO] --- maven-remote-resources-plugin:1.0:process (default) @
>> openejb-corba-deployer ---
>>
>> !!!!! somewhat of a pause here, can be up to 60 seconds sometimes !!!!!
>>
>> [WARNING] org.apache.velocity.runtime.exception.ReferenceException: reference :
>> template = META-INF/DEPENDENCIES.vm [line 40,column 14] : $license.name is not a
>> valid reference.
>> [WARNING] org.apache.velocity.runtime.exception.ReferenceException: reference :
>> template = META-INF/DEPENDENCIES.vm [line 40,column 14] : $license.name is not a
>> valid reference.
>> [INFO]
>> [INFO] --- maven-resources-plugin:2.3:resources (default-resources) @
>> openejb-corba-deployer ---
>> [INFO] Using 'UTF-8' encoding to copy filtered resources.
>> [INFO] skip non existing resourceDirectory
>> /data/geronimo/asf-geronimo-server-trunk/plugins/corba/openejb-corba-deployer/src/main/resources
>> [INFO] skip non existing resourceDirectory
>> /data/geronimo/asf-geronimo-server-trunk/plugins/corba/openejb-corba-deployer/src/main/filtered-resources
>> [INFO] Copying 3 resources
>>
>> !!!!! for the plugins that use the maven-compiler-plugin:2.0.2:compile, of
>> course this will take time as it is compiling !!!!!
>> !!!!! However, the CPU usage only rises for like the first quarter of this wait
>> time. !!!!!
>>
>> [INFO]
>> [INFO] --- car-maven-plugin:3.0-SNAPSHOT:validate-configuration
>> (default-validate-configuration) @ openejb-corba-deployer ---
>> [INFO]
>> [INFO] --- car-maven-plugin:3.0-SNAPSHOT:prepare-plan (default-prepare-plan) @
>> openejb-corba-deployer ---
>> [INFO] Generated:
>> /data/geronimo/asf-geronimo-server-trunk/plugins/corba/openejb-corba-deployer/target/work/plan.xml
>> [INFO]
>> [INFO] --- car-maven-plugin:3.0-SNAPSHOT:verify-no-dependency-change
>> (default-verify-no-dependency-change) @ openejb-corba-deployer ---
>> [INFO]
>> [INFO] --- car-maven-plugin:3.0-SNAPSHOT:prepare-metadata
>> (default-prepare-metadata) @ openejb-corba-deployer ---
>> [INFO]
>> [INFO] --- car-maven-plugin:3.0-SNAPSHOT:package (default-package) @
>> openejb-corba-deployer ---
>> [INFO] Packaging module configuration:
>> /data/geronimo/asf-geronimo-server-trunk/plugins/corba/openejb-corba-deployer/target/work/plan.xml
>> org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator]
>> : Enabling SLF4J API support.
>> org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator]
>> : Enabling Jakarta Commons Logging API support.
>> org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator]
>> : Enabling Log4J API support.
>> org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator]
>> : Enabling Avalon Logger API support.
>> org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator]
>> : Enabling JULI Logger API support.
>> log4j:ERROR A "org.apache.log4j.ConsoleAppender" object is not assignable to a
>> "org.apache.log4j.Appender" variable.
>> log4j:ERROR The class "org.apache.log4j.Appender" was loaded by
>> log4j:ERROR [25.0] whereas object of type
>> log4j:ERROR "org.apache.log4j.ConsoleAppender" was loaded by
>> [ClassRealm[plugin>org.apache.geronimo.buildsupport:car-maven-plugin:3.0-SNAPSHOT--1708152340,
>> parent: sun.misc.Launcher$AppClassLoader@11b86e7]].
>> log4j:ERROR Could not instantiate appender named "CONSOLE".
>> log4j:ERROR A "org.apache.log4j.ConsoleAppender" object is not assignable to a
>> "org.apache.log4j.Appender" variable.
>> log4j:ERROR The class "org.apache.log4j.Appender" was loaded by
>> log4j:ERROR [25.0] whereas object of type
>> log4j:ERROR "org.apache.log4j.ConsoleAppender" was loaded by
>> [ClassRealm[plugin>org.apache.geronimo.buildsupport:car-maven-plugin:3.0-SNAPSHOT--1708152340,
>> parent: sun.misc.Launcher$AppClassLoader@11b86e7]].
>> log4j:ERROR Could not instantiate appender named "A1".
>> log4j:WARN No appenders could be found for logger
>> (org.apache.geronimo.specs.geronimo-osgi-registry).
>> log4j:WARN Please initialize the log4j system properly.
>> log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
>> log4j:ERROR A "org.apache.log4j.ConsoleAppender" object is not assignable to a
>> "org.apache.log4j.Appender" variable.
>> log4j:ERROR The class "org.apache.log4j.Appender" was loaded by
>> log4j:ERROR [25.0] whereas object of type
>> log4j:ERROR "org.apache.log4j.ConsoleAppender" was loaded by
>> [ClassRealm[plugin>org.apache.geronimo.buildsupport:car-maven-plugin:3.0-SNAPSHOT--1708152340,
>> parent: sun.misc.Launcher$AppClassLoader@11b86e7]].
>> log4j:ERROR Could not instantiate appender named "A1".
>>
>> !!!!! always a significant pause here !!!!!
>> !!!!! from a few minutes to several minutes !!!!!
>>
>> [INFO] Started deployer:
>> org.apache.geronimo.framework/geronimo-gbean-deployer/3.0-SNAPSHOT/car
>>
>> !!!!! usually a significant pause here !!!!!
>> !!!!! from less than a minute to a few minutes !!!!!
>>
>> [INFO]
>> [INFO] --- car-maven-plugin:3.0-SNAPSHOT:archive-car (default-archive-car) @
>> openejb-corba-deployer ---
>>
>> !!!!! seemingly always a significant pause here !!!!!
>> !!!!! from a few minutes to 5-to-10 minutes !!!!!
>>
>> org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator]
>> : Disabling SLF4J API support.
>> org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator]
>> : Disabling Jakarta Commons Logging API support.
>> org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator]
>> : Disabling Log4J API support.
>> org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator]
>> : Disabling Avalon Logger API support.
>> org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator]
>> : Disabling JULI Logger API support.
>> [INFO] Expanding:
>> /data/geronimo/asf-geronimo-server-trunk/plugins/corba/openejb-corba-deployer/target/repository/org/apache/geronimo/configs/openejb-corba-deployer/3.0-SNAPSHOT/openejb-corba-deployer-3.0-SNAPSHOT.car
>> into /tmp/archived-file-set.516894452.tmp
>> [INFO] Building jar:
>> /data/geronimo/asf-geronimo-server-trunk/plugins/corba/openejb-corba-deployer/target/openejb-corba-deployer-3.0-SNAPSHOT.car
>> [INFO] Building jar:
>> /data/geronimo/asf-geronimo-server-trunk/plugins/corba/openejb-corba-deployer/target/openejb-corba-deployer-3.0-SNAPSHOT.car
>> [INFO]
>> [INFO] --- geronimo-osgi-plugin:3.0-SNAPSHOT:verify-manifest (verify-manifest) @
>> openejb-corba-deployer ---
>> [INFO]
>> [INFO] --- ianal-maven-plugin:1.0-alpha-1:verify-legal-files (default) @
>> openejb-corba-deployer ---
>> [INFO] Checking legal files in: openejb-corba-deployer-3.0-SNAPSHOT.car
>> [INFO]
>> [INFO] --- maven-install-plugin:2.2:install (default-install) @
>> openejb-corba-deployer ---
>> [INFO] Installing
>> /data/geronimo/asf-geronimo-server-trunk/plugins/corba/openejb-corba-deployer/target/openejb-corba-deployer-3.0-SNAPSHOT.car
>> to
>> /home/ger/.m2/repository/org/apache/geronimo/configs/openejb-corba-deployer/3.0-SNAPSHOT/openejb-corba-deployer-3.0-SNAPSHOT.car
>> [INFO] Installing
>> /data/geronimo/asf-geronimo-server-trunk/plugins/corba/openejb-corba-deployer/pom.xml
>> to
>> /home/ger/.m2/repository/org/apache/geronimo/configs/openejb-corba-deployer/3.0-SNAPSHOT/openejb-corba-deployer-3.0-SNAPSHOT.pom
>> [INFO] Installing
>> /data/geronimo/asf-geronimo-server-trunk/plugins/corba/openejb-corba-deployer/target/resources/META-INF/geronimo-plugin.xml
>> to
>> /home/ger/.m2/repository/org/apache/geronimo/configs/openejb-corba-deployer/3.0-SNAPSHOT/openejb-corba-deployer-3.0-SNAPSHOT.plugin-metadata
>> [INFO]
>> [INFO] --- car-maven-plugin:3.0-SNAPSHOT:update-pluginlist
>> (default-update-pluginlist) @ openejb-corba-deployer ---
>> [INFO]
>> [INFO] ------------------------------------------------------------------------
>> [INFO] Building Geronimo Plugins, Corba :: Client Yoko 3.0-SNAPSHOT
>> [INFO] ------------------------------------------------------------------------
>> ... etc ...
>> -
>>
>>>
>>>>
>>>> Thanks for the excellent tips!
>>>> I'll try some things out, and look at how to reflect the tips in the wiki
>>>> without degrading any affirmation of Best Practices (i.e. running the test cases
>>>> is good).
>>>
>>> No problem. Many thanks for digging into this. Definitely an area we tend to overlook...
>>>
>>> --kevan
>>>
>
Re: Speeding up G3.0 build time
Posted by David Jencks <da...@yahoo.com>.
I've had disk thrashing up my build times from ~30 min to ~2 hours, but never this much. I have no evidence but would suspect a DNS problem resulting in multiple DNS timeouts for each module.
Do you have a more-memory-endowed machine on this network you could try a build on to see if it's faster?
thanks
david jencks
On Jun 22, 2011, at 1:32 PM, Russell E Glaue wrote:
> On 06/22/2011 01:54 PM, Kevan Miller wrote:
>>
>> On Jun 22, 2011, at 1:27 PM, Russell E Glaue wrote:
>>
>>> On 06/22/2011 12:02 PM, Kevan Miller wrote:
>>>>
>>>> On Jun 22, 2011, at 12:09 PM, Russell E Glaue wrote:
>>
>> <snip>
>>
>>>>
>>>>>
>>>>> I am using a very basic build procedure.
>>>>> 1. checkout G3 trunk
>>>>> 2. JAVA_HOME="/path/to/jdk/1.6.0_22"
>>>>> 3. download and install a fresh maven 2.2.1
>>>>> 4. MAVEN_OPTS="-Xmx968m -XX:MaxPermSize=500m -XX:ReservedCodeCacheSize=64m"
>>>>
>>>> My settings are similar. I don't specify '-XX:ReservedCodeCacheSize=64m'.
>>>>
>>>> I run with the following. I know there are others running with larger max heaps. I haven't :
>>>>
>>>> MAVEN_OPTS="-Xmx1024m -XX:MaxPermSize=512m -XX:+HeapDumpOnOutOfMemoryError"
>
> Without the "-XX:ReservedCodeCacheSize=64m" option in MAVEN_OPTS I get this
> OutOfMemory error:
> -
> [INFO] ------------------------------------------------------------------------
> [INFO] Building Geronimo Build Support :: Plugin 3.0-SNAPSHOT
> [INFO] ------------------------------------------------------------------------
> ...<snip>...
> [INFO] --- maven-compiler-plugin:2.0.2:compile (default-compile) @
> buildsupport-maven-plugin ---
> [INFO] Compiling 3 source files to
> /data/geronimo/asf-geronimo-server-trunk/framework/buildsupport/buildsupport-maven-plugin/target/classes
> [INFO]
> [INFO] --- gmaven-plugin:1.2:compile (default) @ buildsupport-maven-plugin ---
> ---------------------------------------------------
> constituent[0]: file:/usr/local/apache-maven-3.0.3/lib/maven-embedder-3.0.3.jar
> ...<snip>...
> constituent[30]: file:/usr/local/apache-maven-3.0.3/lib/maven-compat-3.0.3.jar
> ---------------------------------------------------
> Exception in thread "main" java.lang.VirtualMachineError: out of space in
> CodeCache for adapters
> at
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:212)
> at
> org.codehaus.groovy.ast.builder.AstBuilderTransformation.visit(AstBuilderTransformation.groovy:62)
> at
> org.codehaus.groovy.transform.ASTTransformationVisitor$3.call(ASTTransformationVisitor.java:268)
> at
> org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:799)
> at
> org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:464)
> at
> org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:443)
> at
> org.codehaus.gmaven.runtime.v1_6.ClassCompilerFeature$ClassCompilerImpl.compile(ClassCompilerFeature.java:159)
> at
> org.codehaus.gmaven.plugin.compile.AbstractCompileMojo.compile(AbstractCompileMojo.java:200)
> at
> org.codehaus.gmaven.plugin.compile.AbstractCompileMojo.process(AbstractCompileMojo.java:164)
> at
> org.codehaus.gmaven.plugin.ComponentMojoSupport.doExecute(ComponentMojoSupport.java:60)
> at org.codehaus.gmaven.plugin.MojoSupport.execute(MojoSupport.java:69)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> -
>
> With the "-XX:ReservedCodeCacheSize=64m" flag, I do not get this error.
>
>
>>>
>>> The server I am build on has 1024MB of memory total, and has a dual dual-core
>>> Intel(R) XEON(TM) CPU 2.00GHz with 512KB cache.
>>>
>>> I have tried many JVM configurations, and the one like mine and yours is the
>>> best one I have found. For me, a JVM configuration with less than 400m for
>>> MaxPermSize always ended with an OutOfMemory error on PermGen space.
>>>
>>> The Geronimo dev wiki suggests 200m for MaxPermSize, which never worked for me
>>> for trunk. I always assumed it was because of all the snapshot downloading the
>>> build process has to do. Even after the 2nd or 3rd build, 200m was never enough.
>>
>> Right. So, MaxPermSize=200m is definitely out-of-date. There is/may be some bugs that are increasing this value. However, not really worth our while to pursue at the moment. I don't think MaxPermSize=500m is too prohibitive. More important things to do, ATM.
>>
>> That said -- I'm building on a machine with 8 gigs of real memory. So, 1024MB of real memory seems very small to me. And I suspect that this is the source of your problem... A max heap of 1024MB and MaxPermSize of 512m means your system may be spending a lot of time swapping virtual memory.
>
> So wrote what are your JVM Options set at:
> MAVEN_OPTS="-Xmx1024m -XX:MaxPermSize=512m -XX:+HeapDumpOnOutOfMemoryError"
> Mine are:
> MAVEN_OPTS="-Xmx968m -XX:MaxPermSize=500m -XX:ReservedCodeCacheSize=64m"
>
> The machine I am using has 1024MB of real memory and is dedicated to building
> geronimo (and it is not a virtual server). I set the heap max to 968m to keep
> the memory usage from peaking at 100% of system capacity.
>
> But there is a chance you may be right about the swaping. the machine runs at
> 100% real memory usage (expected) and about ~50% swap.
>
>
> I thinking recommending a minimum amount of real memory a machine should have to
> adequately compile G3 in a reasonable amount of time should be suggested.
> What would you say the minimum recommendation should be? For Windows and Linux?
> 2GB for Windows and 1.5GB for Linux, assuming the machine is dedicated to compiling?
>
>>
>>>
>>>>
>>>>> 5. mvn clean install
>>>>> 6. 13 to 39 hours later == BUILD SUCCESS
>>>>>
>>>>>
>>>>> From observing the build process, it would seem the most used (seemingly paused)
>>>>> time is right before the build process moves on to the next plugin or assembly.
>>>>>
>>>>> This "seemingly paused time" after the assembly I assume is the packaging
>>>>> process, because the resulting output is a huge collection.
>>>>>
>>>>> [INFO] Geronimo Assemblies ............................... SUCCESS [3.995s]
>>>>> [INFO] Geronimo Assemblies :: Minimal + Jetty8 ........... SUCCESS [8:15.210s]
>>>>> [INFO] Geronimo Assemblies :: Java EE 6 Web Profile + Jetty8 SUCCESS [1:57:17.311s]
>>>>> [INFO] Geronimo Assemblies :: Java EE 6 + Jetty8 ......... SUCCESS [1:02:47.374s]
>>>>> [INFO] Geronimo Assemblies :: Minimal + Tomcat7 .......... SUCCESS [8:08.838s]
>>>>> [INFO] Geronimo Assemblies :: Java EE 6 Web Profile + Tomcat7 SUCCESS
>>>>> [1:59:16.619s]
>>>>> [INFO] Geronimo Assemblies :: Java EE 6 + Tomcat7 ........ SUCCESS [1:08:13.854s]
>>>>>
>>>>> That is ~1.5 hours for the "Java EE 6 Web Profile + Jetty8" and "Java EE 6 Web
>>>>> Profile + Tomcat7" assemblies.
>>>>
>>>> Here are my build times. This is running without tests. Which would affect the overall build time. Assembly times would be unaffected -- we don't run any tests when building assemblies.
>>>>
>>>> [INFO] Geronimo Assemblies ............................... SUCCESS [0.163s]
>>>> [INFO] Geronimo Assemblies :: Minimal + Jetty8 ........... SUCCESS [42.253s]
>>>> [INFO] Geronimo Assemblies :: Java EE 6 Web Profile + Jetty8 SUCCESS [1:04.295s]
>>>> [INFO] Geronimo Assemblies :: Java EE 6 + Jetty8 ......... SUCCESS [1:33.097s]
>>>> [INFO] Geronimo Assemblies :: Minimal + Tomcat7 .......... SUCCESS [41.587s]
>>>> [INFO] Geronimo Assemblies :: Java EE 6 Web Profile + Tomcat7 SUCCESS [1:14.409s]
>>>> [INFO] Geronimo Assemblies :: Java EE 6 + Tomcat7 ........ SUCCESS [1:46.333s]
>>>> [INFO] ------------------------------------------------------------------------
>>>> [INFO] BUILD SUCCESS
>>>> [INFO] ------------------------------------------------------------------------
>>>> [INFO] Total time: 28:15.199s
>>>> [INFO] Finished at: Wed Jun 22 12:38:10 EDT 2011
>>>> [INFO] Final Memory: 633M/1011M
>>>> [INFO] ------------------------------------------------------------------------
>>>
>>> Yours is about 1/3 faster than mine.
>>
>> I think you've missed the metric. My times are an order of magnitude (hours vs minutes) better than yours.
>>
>>>>> [INFO] Geronimo Assemblies :: Java EE 6 + Tomcat7 ........ SUCCESS [1:08:13.854s]
>>
>> and
>>
>>>> [INFO] Geronimo Assemblies :: Java EE 6 + Tomcat7 ........ SUCCESS [1:46.333s]
>>
>> That's 68 minutes vs 1 minute 46 seconds. My *total* build time was 28 minutes.
>
> Oh. ya. Let me rub my eyes and take another look there.... your right!
>
>>
>>> But you might have a faster processor too.
>>> Obviously, this part of the build is not the time consumer for me. It is nice to
>>> know this part of the build is supposed to take several hours - that helps me
>>> narrow down the issues.
>
> Okay - this was an incorrect statement by me.
>
>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>> For the plugins, I would assume the same, except that I notice that, of course,
>>>>> the latest snapshot dependencies are being downloaded, and the poms in the maven
>>>>> SNAPSHOT repositories are continually being accessed.
>>>>>
>>>>> I realize that because trunk (G3) largely depends on 3rd-party artifact
>>>>> SNAPSHOTS that these repositories are checked during every build, and new
>>>>> SNAPSHOT libraries are always being downloaded (as is the nature of snapshot
>>>>> releases).
>>>>
>>>> Correct. A local maven proxy (e.g. Nexus) can reduce the overhead.
>>>
>>> So it is worth noting as it already is now.
>>>
>>>>
>>>>>
>>>>> As it is not a simple process for a user to setup a maven repo proxy, and could
>>>>> be a deterrent to someone getting started if it were necessary to install a
>>>>> proxy, I am looking at other methods and tips that might increase the speed of
>>>>> building G3.
>>>>
>>>> I've tried running with a local maven proxy. However, I've found it to be too much trouble to maintain/configure.
>>>
>>> Agreed. At least it is too much trouble if you are not continuously building the
>>> entire trunk every day on the larger scale. So too much to ask a G3 beginner to do.
>>
>> Too much to ask of a new maven user -- I agree.
>>
>>>
>>>>
>>>>>
>>>>> Is this feasible? Or would we just say, that because of the nature of SNAPSHOT
>>>>> builds and their dependencies on 3rd-party SNAPSHOT artifacts, there is no real
>>>>> means to improving build speed unless a proxy is utilized?
>>>>> If the later is true, I would like to add this note in the wiki's build
>>>>> documentation. And also warn those who choose to build without a proxy may
>>>>> experience a long build time.
>>>>
>>>> While I'm thinking about it -- what is your network environment? The focus on proxies imply that your slow build times are predominantly network issue. Are you certain that is the case?
>>>
>>> We have about ~14Mb/s speed to the Internet. Our backplane is Gigabit Ethernet.
>>> We are connected to a major Internet backbone provider.
>>> I have been wondering if the problem is responsiveness of the maven repo sites.
>>> I have been seeing on occasion a refusal to download an artifact from the site,
>>> where as I was able to download it within a browser from the same URL.
>>> So I wonder if the repo sites are either metering the usage on a per user or
>>> session basis.
>>
>> I'm building on my home broadband connection. Probably similar speeds. I think we should identify the source of your extremely slow build time.
>>
>> If remote repository lookups are the cause of your problems, 'mvn -o clean install' should result in a much faster build time. However, I suspect that it won't make much difference at all...
>
> It seems a lot of "pauses" in the build process (while using the
> '-DskipTests=true' flag) is at the end of building each plugin, and that looks
> like this (example plugin build output)...
> (Note: almost every plugin gives the log4j errors)
> -
> [INFO] ------------------------------------------------------------------------
> [INFO] Building Geronimo Plugins, Corba :: Deployer 3.0-SNAPSHOT
> [INFO] ------------------------------------------------------------------------
> [INFO]
> [INFO] --- maven-clean-plugin:2.3:clean (default-clean) @ openejb-corba-deployer ---
> [INFO]
> [INFO] --- genesis-maven-plugin:2.0:validate-configuration (default) @
> openejb-corba-deployer ---
> [INFO]
> [INFO] --- geronimo-property-plugin:3.0-SNAPSHOT:set-property (set-property) @
> openejb-corba-deployer ---
> [INFO]
> [INFO] --- maven-enforcer-plugin:1.0-beta-1:enforce (default) @
> openejb-corba-deployer ---
> [INFO]
> [INFO] --- maven-remote-resources-plugin:1.0:process (default) @
> openejb-corba-deployer ---
>
> !!!!! somewhat of a pause here, can be up to 60 seconds sometimes !!!!!
>
> [WARNING] org.apache.velocity.runtime.exception.ReferenceException: reference :
> template = META-INF/DEPENDENCIES.vm [line 40,column 14] : $license.name is not a
> valid reference.
> [WARNING] org.apache.velocity.runtime.exception.ReferenceException: reference :
> template = META-INF/DEPENDENCIES.vm [line 40,column 14] : $license.name is not a
> valid reference.
> [INFO]
> [INFO] --- maven-resources-plugin:2.3:resources (default-resources) @
> openejb-corba-deployer ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory
> /data/geronimo/asf-geronimo-server-trunk/plugins/corba/openejb-corba-deployer/src/main/resources
> [INFO] skip non existing resourceDirectory
> /data/geronimo/asf-geronimo-server-trunk/plugins/corba/openejb-corba-deployer/src/main/filtered-resources
> [INFO] Copying 3 resources
>
> !!!!! for the plugins that use the maven-compiler-plugin:2.0.2:compile, of
> course this will take time as it is compiling !!!!!
> !!!!! However, the CPU usage only rises for like the first quarter of this wait
> time. !!!!!
>
> [INFO]
> [INFO] --- car-maven-plugin:3.0-SNAPSHOT:validate-configuration
> (default-validate-configuration) @ openejb-corba-deployer ---
> [INFO]
> [INFO] --- car-maven-plugin:3.0-SNAPSHOT:prepare-plan (default-prepare-plan) @
> openejb-corba-deployer ---
> [INFO] Generated:
> /data/geronimo/asf-geronimo-server-trunk/plugins/corba/openejb-corba-deployer/target/work/plan.xml
> [INFO]
> [INFO] --- car-maven-plugin:3.0-SNAPSHOT:verify-no-dependency-change
> (default-verify-no-dependency-change) @ openejb-corba-deployer ---
> [INFO]
> [INFO] --- car-maven-plugin:3.0-SNAPSHOT:prepare-metadata
> (default-prepare-metadata) @ openejb-corba-deployer ---
> [INFO]
> [INFO] --- car-maven-plugin:3.0-SNAPSHOT:package (default-package) @
> openejb-corba-deployer ---
> [INFO] Packaging module configuration:
> /data/geronimo/asf-geronimo-server-trunk/plugins/corba/openejb-corba-deployer/target/work/plan.xml
> org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator]
> : Enabling SLF4J API support.
> org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator]
> : Enabling Jakarta Commons Logging API support.
> org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator]
> : Enabling Log4J API support.
> org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator]
> : Enabling Avalon Logger API support.
> org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator]
> : Enabling JULI Logger API support.
> log4j:ERROR A "org.apache.log4j.ConsoleAppender" object is not assignable to a
> "org.apache.log4j.Appender" variable.
> log4j:ERROR The class "org.apache.log4j.Appender" was loaded by
> log4j:ERROR [25.0] whereas object of type
> log4j:ERROR "org.apache.log4j.ConsoleAppender" was loaded by
> [ClassRealm[plugin>org.apache.geronimo.buildsupport:car-maven-plugin:3.0-SNAPSHOT--1708152340,
> parent: sun.misc.Launcher$AppClassLoader@11b86e7]].
> log4j:ERROR Could not instantiate appender named "CONSOLE".
> log4j:ERROR A "org.apache.log4j.ConsoleAppender" object is not assignable to a
> "org.apache.log4j.Appender" variable.
> log4j:ERROR The class "org.apache.log4j.Appender" was loaded by
> log4j:ERROR [25.0] whereas object of type
> log4j:ERROR "org.apache.log4j.ConsoleAppender" was loaded by
> [ClassRealm[plugin>org.apache.geronimo.buildsupport:car-maven-plugin:3.0-SNAPSHOT--1708152340,
> parent: sun.misc.Launcher$AppClassLoader@11b86e7]].
> log4j:ERROR Could not instantiate appender named "A1".
> log4j:WARN No appenders could be found for logger
> (org.apache.geronimo.specs.geronimo-osgi-registry).
> log4j:WARN Please initialize the log4j system properly.
> log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
> log4j:ERROR A "org.apache.log4j.ConsoleAppender" object is not assignable to a
> "org.apache.log4j.Appender" variable.
> log4j:ERROR The class "org.apache.log4j.Appender" was loaded by
> log4j:ERROR [25.0] whereas object of type
> log4j:ERROR "org.apache.log4j.ConsoleAppender" was loaded by
> [ClassRealm[plugin>org.apache.geronimo.buildsupport:car-maven-plugin:3.0-SNAPSHOT--1708152340,
> parent: sun.misc.Launcher$AppClassLoader@11b86e7]].
> log4j:ERROR Could not instantiate appender named "A1".
>
> !!!!! always a significant pause here !!!!!
> !!!!! from a few minutes to several minutes !!!!!
>
> [INFO] Started deployer:
> org.apache.geronimo.framework/geronimo-gbean-deployer/3.0-SNAPSHOT/car
>
> !!!!! usually a significant pause here !!!!!
> !!!!! from less than a minute to a few minutes !!!!!
>
> [INFO]
> [INFO] --- car-maven-plugin:3.0-SNAPSHOT:archive-car (default-archive-car) @
> openejb-corba-deployer ---
>
> !!!!! seemingly always a significant pause here !!!!!
> !!!!! from a few minutes to 5-to-10 minutes !!!!!
>
> org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator]
> : Disabling SLF4J API support.
> org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator]
> : Disabling Jakarta Commons Logging API support.
> org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator]
> : Disabling Log4J API support.
> org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator]
> : Disabling Avalon Logger API support.
> org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator]
> : Disabling JULI Logger API support.
> [INFO] Expanding:
> /data/geronimo/asf-geronimo-server-trunk/plugins/corba/openejb-corba-deployer/target/repository/org/apache/geronimo/configs/openejb-corba-deployer/3.0-SNAPSHOT/openejb-corba-deployer-3.0-SNAPSHOT.car
> into /tmp/archived-file-set.516894452.tmp
> [INFO] Building jar:
> /data/geronimo/asf-geronimo-server-trunk/plugins/corba/openejb-corba-deployer/target/openejb-corba-deployer-3.0-SNAPSHOT.car
> [INFO] Building jar:
> /data/geronimo/asf-geronimo-server-trunk/plugins/corba/openejb-corba-deployer/target/openejb-corba-deployer-3.0-SNAPSHOT.car
> [INFO]
> [INFO] --- geronimo-osgi-plugin:3.0-SNAPSHOT:verify-manifest (verify-manifest) @
> openejb-corba-deployer ---
> [INFO]
> [INFO] --- ianal-maven-plugin:1.0-alpha-1:verify-legal-files (default) @
> openejb-corba-deployer ---
> [INFO] Checking legal files in: openejb-corba-deployer-3.0-SNAPSHOT.car
> [INFO]
> [INFO] --- maven-install-plugin:2.2:install (default-install) @
> openejb-corba-deployer ---
> [INFO] Installing
> /data/geronimo/asf-geronimo-server-trunk/plugins/corba/openejb-corba-deployer/target/openejb-corba-deployer-3.0-SNAPSHOT.car
> to
> /home/ger/.m2/repository/org/apache/geronimo/configs/openejb-corba-deployer/3.0-SNAPSHOT/openejb-corba-deployer-3.0-SNAPSHOT.car
> [INFO] Installing
> /data/geronimo/asf-geronimo-server-trunk/plugins/corba/openejb-corba-deployer/pom.xml
> to
> /home/ger/.m2/repository/org/apache/geronimo/configs/openejb-corba-deployer/3.0-SNAPSHOT/openejb-corba-deployer-3.0-SNAPSHOT.pom
> [INFO] Installing
> /data/geronimo/asf-geronimo-server-trunk/plugins/corba/openejb-corba-deployer/target/resources/META-INF/geronimo-plugin.xml
> to
> /home/ger/.m2/repository/org/apache/geronimo/configs/openejb-corba-deployer/3.0-SNAPSHOT/openejb-corba-deployer-3.0-SNAPSHOT.plugin-metadata
> [INFO]
> [INFO] --- car-maven-plugin:3.0-SNAPSHOT:update-pluginlist
> (default-update-pluginlist) @ openejb-corba-deployer ---
> [INFO]
> [INFO] ------------------------------------------------------------------------
> [INFO] Building Geronimo Plugins, Corba :: Client Yoko 3.0-SNAPSHOT
> [INFO] ------------------------------------------------------------------------
> ... etc ...
> -
>
>>
>>>
>>> Thanks for the excellent tips!
>>> I'll try some things out, and look at how to reflect the tips in the wiki
>>> without degrading any affirmation of Best Practices (i.e. running the test cases
>>> is good).
>>
>> No problem. Many thanks for digging into this. Definitely an area we tend to overlook...
>>
>> --kevan
>>
Re: Speeding up G3.0 build time
Posted by Rex Wang <rw...@gmail.com>.
FYI,
I just built the trunk with the test successfully, with
-Xms256m -Xmx1024m -XX:MaxPermSize=1024m
sun_jdk6_22
Ubuntu 9.10
and the time is : (not a clean maven repo in back)
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO] ------------------------------------------------------------------------
[INFO] Geronimo .............................................. SUCCESS [4.609s]
[INFO] Geronimo Framework .................................... SUCCESS [0.129s]
[INFO] Geronimo Build Support ................................ SUCCESS [0.188s]
[INFO] Geronimo Build Support :: OSGi Plugin ................. SUCCESS [4.393s]
[INFO] Geronimo Framework, Modules ........................... SUCCESS [0.224s]
[INFO] Geronimo Test Support :: Common ....................... SUCCESS [3.193s]
[INFO] Geronimo Test Support ................................. SUCCESS [0.220s]
[INFO] Geronimo Test Support :: Selenium ..................... SUCCESS [1.876s]
[INFO] Geronimo Framework, Modules :: Main ................... SUCCESS [5.795s]
[INFO] Geronimo Framework, Modules :: CLI .................... SUCCESS [2.398s]
[INFO] Geronimo Framework, Modules :: RMI Loader ............. SUCCESS [0.895s]
[INFO] Geronimo Framework, Modules :: Crypto ................. SUCCESS [5.066s]
[INFO] Geronimo Framework, Modules :: Kernel ................. SUCCESS [11.416s]
[INFO] Geronimo Framework, Modules :: Common ................. SUCCESS [3.092s]
[INFO] Geronimo Framework, Modules :: PAX Logging ............ SUCCESS [1.645s]
[INFO] Geronimo Framework, Modules :: System ................. SUCCESS [8.261s]
[INFO] Geronimo Framework, Modules :: Plugin ................. SUCCESS [4.880s]
[INFO] Geronimo Framework, Modules :: Deploy Config .......... SUCCESS [0.930s]
[INFO] Geronimo Framework, Modules :: Bundle Recorder ........ SUCCESS [1.583s]
[INFO] Geronimo Framework, Modules :: Deploy JSR-88 .......... SUCCESS [8.326s]
[INFO] Geronimo Build Support :: Geronimo .................... SUCCESS [7.907s]
[INFO] Geronimo Test Support :: Commands ..................... SUCCESS [3.551s]
[INFO] Geronimo Test Support :: Packaging .................... SUCCESS [0.419s]
[INFO] Geronimo Test Support, Test Deployment J2EE 1.3 ....... SUCCESS [0.136s]
[INFO] Geronimo Test Support, Test Deployment J2EE 1.3 :: EJB SUCCESS [1.057s]
[INFO] Geronimo Test Support, Test Deployment J2EE 1.3 :: WAR SUCCESS [1.885s]
[INFO] Geronimo Test Support, Test Deployment J2EE 1.3 :: RAR SUCCESS [0.625s]
[INFO] Geronimo Test Support, Test Deployment J2EE 1.3 :: EAR SUCCESS [0.407s]
[INFO] Geronimo Test Support, Test Deployment J2EE 1.4 ....... SUCCESS [0.108s]
[INFO] Geronimo Test Support, Test Deployment J2EE 1.4 :: EJB SUCCESS [1.017s]
[INFO] Geronimo Test Support, Test Deployment J2EE 1.4 :: WAR SUCCESS [0.895s]
[INFO] Geronimo Test Support, Test Deployment J2EE 1.4 :: RAR SUCCESS [0.431s]
[INFO] Geronimo Test Support, Test Deployment J2EE 1.4 :: EAR SUCCESS [0.184s]
[INFO] Geronimo Test Support, Test Deployment JavaEE 5 ....... SUCCESS [0.126s]
[INFO] Geronimo Test Support, Test Deployment JavaEE 5 :: EJB SUCCESS [1.414s]
[INFO] Geronimo Test Support, Test Deployment JavaEE 5 :: WAR SUCCESS [0.946s]
[INFO] Geronimo Test Support, Test Deployment JavaEE 5 :: RAR SUCCESS [0.387s]
[INFO] Geronimo Test Support, Test Deployment JavaEE 5 :: EAR SUCCESS [0.291s]
[INFO] Geronimo Framework, Modules :: OBR .................... SUCCESS [2.609s]
[INFO] Geronimo Framework, Modules :: Deployment ............. SUCCESS [4.258s]
[INFO] Geronimo Framework, Modules :: Service Builder ........ SUCCESS [6.918s]
[INFO] Geronimo Framework, Modules :: Transformer ............ SUCCESS [1.043s]
[INFO] Geronimo Framework, Modules :: Deploy Tool ............ SUCCESS [2.510s]
[INFO] Geronimo Framework, Modules :: Shell .................. SUCCESS [0.691s]
[INFO] Geronimo Framework, Modules :: Shell Commands ......... SUCCESS [3.411s]
[INFO] Geronimo Framework, Modules :: Diagnose Shell Command . SUCCESS [1.526s]
[INFO] Geronimo Framework, Modules :: blueprint .............. SUCCESS [1.073s]
[INFO] Geronimo Framework, Modules :: Management API ......... SUCCESS [1.975s]
[INFO] Geronimo Framework, Modules :: Core ................... SUCCESS [26.243s]
[INFO] Geronimo Framework, Modules :: Deploy JSR-88 Bootstrapper
SUCCESS [0.957s]
[INFO] Geronimo Framework, Modules :: Deploy JSR-88 Standalone SUCCESS [2.301s]
[INFO] Geronimo Framework, Modules :: Interceptor ............ SUCCESS [1.120s]
[INFO] Geronimo Framework, Modules :: JDBC ................... SUCCESS [1.142s]
[INFO] Geronimo Framework, Modules :: Security ............... SUCCESS [9.605s]
[INFO] Geronimo Framework, Modules :: JMX Remoting ........... SUCCESS [2.126s]
[INFO] Geronimo Framework, Modules :: Naming ................. SUCCESS [3.535s]
[INFO] Geronimo Framework, Modules :: OSGi Framework Hook .... SUCCESS [1.283s]
[INFO] Geronimo Build Support :: Plugin ...................... SUCCESS [6.156s]
[INFO] Geronimo Build Support :: CAR ......................... SUCCESS [6.026s]
[INFO] Geronimo Build Support :: Testsuite Plugin ............ SUCCESS [1.996s]
[INFO] Archetype - geronimo-plugin-archetype ................. SUCCESS [0.508s]
[INFO] Archetype - geronimo-assembly-archetype ............... SUCCESS [0.507s]
[INFO] Geronimo Build Support :: Set Property Plugin ......... SUCCESS [1.025s]
[INFO] Geronimo Framework, Configs ........................... SUCCESS [0.148s]
[INFO] Geronimo Framework, Configs :: GBean Deployer Boostrap SUCCESS [3.660s]
[INFO] Geronimo Framework, Configs :: J2EE System ............ SUCCESS [3.014s]
[INFO] Geronimo Framework, Configs :: RMI Naming ............. SUCCESS [2.691s]
[INFO] Geronimo Framework, Configs :: Plugin Management ...... SUCCESS [5.234s]
[INFO] Geronimo Framework, Configs :: GBean Deployer ......... SUCCESS [1.915s]
[INFO] Geronimo Framework, Configs :: Client System .......... SUCCESS [1.798s]
[INFO] Geronimo Framework, Configs :: J2EE Security .......... SUCCESS [2.626s]
[INFO] Geronimo Framework, Configs :: JSR-88 CLI ............. SUCCESS [2.520s]
[INFO] Geronimo Framework, Configs :: JSR-88 DeploymentFactory SUCCESS [5.676s]
[INFO] Geronimo Framework, Configs :: Online Deployer ........ SUCCESS [3.093s]
[INFO] Geronimo Framework, Configs :: Offline Deployer ....... SUCCESS [1.694s]
[INFO] Geronimo Framework, Configs :: Server Security Configuration
SUCCESS [2.746s]
[INFO] Geronimo Framework, Configs :: Shutdown ............... SUCCESS [2.522s]
[INFO] Geronimo Framework, Configs :: JMX Security Configuration
SUCCESS [2.461s]
[INFO] Geronimo Framework, Configs :: Bundle Recorder ........ SUCCESS [1.522s]
[INFO] Geronimo Assemblies :: Karaf Boilerplate Framework .... SUCCESS [31.913s]
[INFO] Geronimo Plugin Groups ................................ SUCCESS [0.143s]
[INFO] Geronimo Plugin Group :: Framework .................... SUCCESS [1.075s]
[INFO] Geronimo Assemblies ................................... SUCCESS [0.143s]
[INFO] Geronimo Assemblies :: Framework ...................... SUCCESS [7.047s]
[INFO] Geronimo Plugins ...................................... SUCCESS [0.334s]
[INFO] Geronimo Plugins, Pluto ............................... SUCCESS [0.168s]
[INFO] Geronimo Plugins, Pluto :: Core ....................... SUCCESS [2.063s]
[INFO] Geronimo Plugins, Pluto :: Support .................... SUCCESS [6.016s]
[INFO] Geronimo Plugins, System Database ..................... SUCCESS [0.117s]
[INFO] Geronimo Plugins, System Database :: Derby ............ SUCCESS [5.733s]
[INFO] Geronimo Plugins, J2EE ................................ SUCCESS [0.150s]
[INFO] Geronimo Framework, Modules :: J2EE ................... SUCCESS [4.138s]
[INFO] Geronimo Plugins, J2EE :: Server ...................... SUCCESS [2.501s]
[INFO] Geronimo Plugins, J2EE :: Schema ...................... SUCCESS [3.262s]
[INFO] Geronimo Plugins, J2EE :: Builder ..................... SUCCESS [19.202s]
[INFO] Geronimo Plugins, J2EE :: Naming Builder .............. SUCCESS [10.310s]
[INFO] Geronimo Plugins, J2EE :: Web ......................... SUCCESS [2.285s]
[INFO] Geronimo Plugins, J2EE :: Security Builder ............ SUCCESS [9.974s]
[INFO] Geronimo Plugins, J2EE :: Test DDBeans ................ SUCCESS [3.174s]
[INFO] Geronimo Plugins, J2EE :: Web 2.5 Builder ............. SUCCESS [16.960s]
[INFO] Geronimo Plugins, J2EE :: Deployer .................... SUCCESS [4.720s]
[INFO] Geronimo Plugins, Connector 1.6 ....................... SUCCESS [0.176s]
[INFO] Geronimo Plugins, Connector 1.6 :: Transaction ........ SUCCESS [1.715s]
[INFO] Geronimo Plugins, BVal ................................ SUCCESS [0.340s]
[INFO] Geronimo Plugins, BVal :: Core ........................ SUCCESS [2.474s]
[INFO] Geronimo Plugins, Connector 1.6 :: Connector wrappers . SUCCESS [4.102s]
[INFO] Geronimo Plugins, Connector 1.6 :: Builder ............ SUCCESS [16.969s]
[INFO] Geronimo Plugins, BVal :: Builder ..................... SUCCESS [2.873s]
[INFO] Geronimo Plugins, BVal :: Deployer .................... SUCCESS [7.898s]
[INFO] Geronimo Plugins, Connector 1.6 :: Transaction Manager (JTA11)
SUCCESS [3.583s]
[INFO] Geronimo Plugins, Connector 1.6 :: Deployer ........... SUCCESS [4.881s]
[INFO] Geronimo Plugins, System Database :: System Database .. SUCCESS [7.092s]
[INFO] Geronimo Plugins, Console ............................. SUCCESS [0.202s]
[INFO] Geronimo Plugins, Console :: Core ..................... SUCCESS [3.937s]
[INFO] Geronimo Plugins, Console :: Configuration Converter .. SUCCESS [2.992s]
[INFO] Geronimo Plugins, J2EE :: JSR-88 RAR Configurer ....... SUCCESS [2.820s]
[INFO] Geronimo Plugins, System Database :: Portlets ......... SUCCESS [41.564s]
[INFO] Geronimo Plugins, JavaEE :: Builder Support ........... SUCCESS [2.733s]
[INFO] Geronimo Plugins, WAB ................................. SUCCESS [0.201s]
[INFO] Geronimo Plugins, WAB :: WAB .......................... SUCCESS [1.828s]
[INFO] Geronimo Plugins, OpenWebBeans ........................ SUCCESS [0.206s]
[INFO] Geronimo Plugins, OpenWebBeans :: Core ................ SUCCESS [4.928s]
[INFO] Geronimo Plugins, Web Services ........................ SUCCESS [0.246s]
[INFO] Geronimo Plugins, Web Services :: Core ................ SUCCESS [6.993s]
[INFO] Geronimo Plugins, Jasper .............................. SUCCESS [0.231s]
[INFO] Geronimo Plugins, Jasper :: Core ...................... SUCCESS [2.606s]
[INFO] Geronimo Plugins, Jetty 8 ............................. SUCCESS [0.222s]
[INFO] Geronimo Plugins, Jetty 8 :: Core ..................... SUCCESS [31.166s]
[INFO] Geronimo Plugins, OpenWebBeans :: OpenWebBeans ........ SUCCESS [4.491s]
[INFO] Geronimo Plugins, Jasper :: Jasper .................... SUCCESS [3.443s]
[INFO] Geronimo Plugins, Jetty 8 :: Jetty 8 .................. SUCCESS [7.384s]
[INFO] Geronimo Plugins, Jetty 8 :: Builder .................. SUCCESS [9.746s]
[INFO] Geronimo Plugins, Jetty 8 :: Deployer ................. SUCCESS [9.305s]
[INFO] Geronimo Plugins, Jasper :: Builder ................... SUCCESS [4.483s]
[INFO] Geronimo Plugins, Jasper :: Deployer .................. SUCCESS [13.491s]
[INFO] Geronimo Plugins, Console :: XSSXSRF Filter ........... SUCCESS [1.962s]
[INFO] Geronimo Plugins, Console :: Portal Driver ............ SUCCESS [9.582s]
[INFO] Geronimo Plugins, Console :: Base Portlets ............ SUCCESS [23.108s]
[INFO] Geronimo Plugins, Console :: EAR ...................... SUCCESS [0.575s]
[INFO] Geronimo Plugins, Dojo ................................ SUCCESS [0.170s]
[INFO] Geronimo Plugins, Dojo :: Jetty ....................... SUCCESS [14.758s]
[INFO] Geronimo Plugins, Console :: Jetty .................... SUCCESS [9.327s]
[INFO] Geronimo Plugins, Connector 1.6 :: Database Connectors SUCCESS [1.721s]
[INFO] Geronimo Plugins, Console :: System Database (Jetty) .. SUCCESS [9.409s]
[INFO] Geronimo Plugins, Tomcat .............................. SUCCESS [0.180s]
[INFO] Geronimo Plugins, Tomcat :: Core ...................... SUCCESS
[5:43.695s]
[INFO] Geronimo Plugins, Tomcat :: Tomcat .................... SUCCESS [9.654s]
[INFO] Geronimo Plugins, Tomcat :: Builder ................... SUCCESS [11.912s]
[INFO] Geronimo Plugins, Tomcat :: Deployer .................. SUCCESS [9.847s]
[INFO] Geronimo Plugins, Dojo :: Tomcat ...................... SUCCESS [18.542s]
[INFO] Geronimo Plugins, Console :: Tomcat ................... SUCCESS [9.346s]
[INFO] Geronimo Plugins, Console :: System Database (Tomcat) . SUCCESS [9.205s]
[INFO] Geronimo Plugins, ActiveMQ v5 ......................... SUCCESS [0.202s]
[INFO] Geronimo Plugins, ActiveMQ v5 :: Management Interfaces SUCCESS [1.961s]
[INFO] Geronimo Plugins, ActiveMQ v5 :: Blueprint ............ SUCCESS [8.592s]
[INFO] Geronimo Plugins, ActiveMQ v5 :: Broker using blueprint SUCCESS [5.745s]
[INFO] Geronimo Plugins, ActiveMQ v5 :: Resource Adapter Core SUCCESS [1.426s]
[INFO] Geronimo Plugins, ActiveMQ v5 :: Resource Adapter ..... SUCCESS [7.015s]
[INFO] Geronimo Plugins, ActiveMQ v5 :: Portlets ............. SUCCESS [16.295s]
[INFO] Geronimo Plugins, ActiveMQ v5 :: Console (Jetty) ...... SUCCESS [11.887s]
[INFO] Geronimo Plugins, ActiveMQ v5 :: Console (Tomcat) ..... SUCCESS [8.272s]
[INFO] Geronimo Plugins, AspectJ ............................. SUCCESS [0.234s]
[INFO] Geronimo Plugins, AspectJ :: AspectJ .................. SUCCESS [2.256s]
[INFO] Geronimo Plugins, AspectJ :: AspectJ .................. SUCCESS [5.320s]
[INFO] Geronimo Plugins, Web Services :: Common .............. SUCCESS [4.824s]
[INFO] Geronimo Plugins, OpenJPA2 ............................ SUCCESS [0.229s]
[INFO] Geronimo Plugins, OpenJPA2 :: Persistence 2.0 ......... SUCCESS [9.581s]
[INFO] Geronimo Plugins, OpenEJB ............................. SUCCESS [0.185s]
[INFO] Geronimo Plugins, OpenEJB :: Core ..................... SUCCESS [7.401s]
[INFO] Geronimo Plugins, OpenJPA2 :: Core .................... SUCCESS [2.708s]
[INFO] Geronimo Plugins, OpenJPA2 :: Aries JPA ............... SUCCESS [1.973s]
[INFO] Geronimo Plugins, OpenJPA2 :: CAR ..................... SUCCESS [3.523s]
[INFO] Geronimo Plugins, OpenEJB :: OpenEJB .................. SUCCESS [6.287s]
[INFO] Geronimo Plugins, AXIS ................................ SUCCESS [0.189s]
[INFO] Geronimo Plugins, AXIS :: Core ........................ SUCCESS [16.474s]
[INFO] Geronimo Plugins, AXIS :: AXIS ........................ SUCCESS [19.372s]
[INFO] Geronimo Plugins, OpenEJB :: Builder .................. SUCCESS [13.390s]
[INFO] Geronimo Plugins, OpenEJB :: Deployer ................. SUCCESS [6.640s]
[INFO] Geronimo Plugins, Web Services :: Builder ............. SUCCESS [8.436s]
[INFO] Geronimo Plugins, AXIS :: Builder ..................... SUCCESS [11.345s]
[INFO] Geronimo Plugins, AXIS :: Deployer .................... SUCCESS [13.469s]
[INFO] Unnamed -
org.apache.geronimo.plugins:axis-jetty-server:server-assembly:3.0-SNAPSHOT
SUCCESS [18.808s]
[INFO] Geronimo Plugins, JAXWS ............................... SUCCESS [0.648s]
[INFO] Geronimo Plugins, JAXWS :: Core ....................... SUCCESS [8.212s]
[INFO] Geronimo Plugins, AXIS2 ............................... SUCCESS [0.191s]
[INFO] Geronimo Plugins, AXIS2 :: Core ....................... SUCCESS [31.754s]
[INFO] Geronimo Plugins, AXIS2 :: AXIS2 ...................... SUCCESS [8.697s]
[INFO] Geronimo Plugins, JAXWS :: Builder .................... SUCCESS [8.106s]
[INFO] Geronimo Plugins, JAXWS :: Deployer ................... SUCCESS [5.164s]
[INFO] Geronimo Plugins, AXIS2 :: Builder .................... SUCCESS [3.013s]
[INFO] Geronimo Plugins, AXIS2 :: Deployer ................... SUCCESS [5.842s]
[INFO] Geronimo Plugins, AXIS2 :: EJB Core ................... SUCCESS [3.677s]
[INFO] Geronimo Plugins, AXIS2 :: EJB ........................ SUCCESS [10.376s]
[INFO] Geronimo Plugins, JAXWS :: EJB Builder ................ SUCCESS [3.372s]
[INFO] Geronimo Plugins, JAXWS :: EJB Deployer ............... SUCCESS [8.571s]
[INFO] Geronimo Plugins, AXIS2 :: EJB Builder ................ SUCCESS [3.169s]
[INFO] Geronimo Plugins, AXIS2 :: EJB Deployer ............... SUCCESS [9.501s]
[INFO] Geronimo Plugins, Client .............................. SUCCESS [0.212s]
[INFO] Geronimo Plugins, Client :: Core ...................... SUCCESS [1.750s]
[INFO] Geronimo Plugins, Client :: Client .................... SUCCESS [6.255s]
[INFO] Geronimo Plugins, Client :: Security .................. SUCCESS [5.583s]
[INFO] Geronimo Plugins, Connector 1.6 :: Client transaction . SUCCESS [3.680s]
[INFO] Geronimo Plugins, Client :: Builder ................... SUCCESS [7.882s]
[INFO] Geronimo Plugins, Client :: Deployer .................. SUCCESS [6.519s]
[INFO] Geronimo Plugins, Clustering .......................... SUCCESS [0.187s]
[INFO] Geronimo Plugins, Clustering :: Core .................. SUCCESS [1.872s]
[INFO] Geronimo Plugins, Clustering :: WADI Core ............. SUCCESS [7.372s]
[INFO] Geronimo Plugins, Clustering :: Farm core ............. SUCCESS [1.969s]
[INFO] Geronimo Plugins, Clustering :: Farm using Deployment . SUCCESS [6.573s]
[INFO] Geronimo Plugins, Clustering :: Farm using Plugins .... SUCCESS [5.061s]
[INFO] Geronimo Plugins, Clustering :: Clustering ............ SUCCESS [3.059s]
[INFO] Geronimo Plugins, Clustering :: WADI .................. SUCCESS [5.314s]
[INFO] Geronimo Plugins, Clustering :: Farming ............... SUCCESS [5.252s]
[INFO] Geronimo Plugins, Clustering :: Plugin Farm Datasource SUCCESS [4.415s]
[INFO] Geronimo Plugins, Clustering :: Plugin Farm ........... SUCCESS [5.935s]
[INFO] Geronimo Plugins, Clustering :: Plugin Farm Member .... SUCCESS [3.489s]
[INFO] Geronim Plugin Farm Node Server Assembly .............. SUCCESS [10.315s]
[INFO] Geronimo Plugins, Console :: Plugin and Deployment Portlets
SUCCESS [12.435s]
[INFO] Geronimo Plugins, Console :: Plugin and Deployment Portlets
(Jetty) SUCCESS [7.802s]
[INFO] Geronimo Plugins, Console :: Plugin and Deployment Portlets
(Tomcat) SUCCESS [7.683s]
[INFO] Geronimo Plugins, Corba ............................... SUCCESS [0.208s]
[INFO] Geronimo Plugins, Corba :: Core ....................... SUCCESS [21.436s]
[INFO] Geronimo Plugins, Corba :: Builder .................... SUCCESS [11.364s]
[INFO] Geronimo Plugins, Corba :: Yoko ....................... SUCCESS [23.191s]
[INFO] Geronimo Plugins, Corba :: Deployer ................... SUCCESS [4.417s]
[INFO] Geronimo Plugins, Corba :: Client Yoko ................ SUCCESS [6.211s]
[INFO] Geronimo Plugins, Corba :: Yoko ORB ................... SUCCESS [7.482s]
[INFO] Geronimo Plugins, CXF ................................. SUCCESS [0.087s]
[INFO] Geronimo Plugins, CXF :: Core ......................... SUCCESS [49.323s]
[INFO] Geronimo Plugins, CXF :: CXF .......................... SUCCESS [11.649s]
[INFO] Geronimo Plugins, CXF :: Builder ...................... SUCCESS [2.833s]
[INFO] Geronimo Plugins, CXF :: Deployer ..................... SUCCESS [5.071s]
[INFO] Geronimo Plugins, CXF :: EJB Core ..................... SUCCESS [3.109s]
[INFO] Geronimo Plugins, CXF :: EJB .......................... SUCCESS [5.610s]
[INFO] Geronimo Plugins, CXF :: EJB Builder .................. SUCCESS [2.753s]
[INFO] Geronimo Plugins, CXF :: EJB Deployer ................. SUCCESS [6.706s]
[INFO] Geronimo Plugins, Debug Views ......................... SUCCESS [0.176s]
[INFO] Geronimo Plugins, Debug Views :: Portlets ............. SUCCESS [5.566s]
[INFO] Geronimo Plugins, Console :: Debug Views (Tomcat) ..... SUCCESS [5.567s]
[INFO] Geronimo Plugins, Console :: Debug Views (Jetty) ...... SUCCESS [5.198s]
[INFO] Geronimo Plugins, Hot Deploy .......................... SUCCESS [0.098s]
[INFO] Geronimo Plugins, Hot Deploy :: Core .................. SUCCESS [5.900s]
[INFO] Geronimo Plugins, Hot Deploy :: Deployer .............. SUCCESS [5.017s]
[INFO] Geronimo Plugins, J2EE :: JSR-88 EAR Configurer ....... SUCCESS [3.235s]
[INFO] Geronimo Plugins, J2EE :: JSR-88 JAR Configurer ....... SUCCESS [2.099s]
[INFO] Geronimo Plugins, J2EE :: JSR-88 WAR Configurer ....... SUCCESS [1.699s]
[INFO] Geronimo Plugins, JavaMail ............................ SUCCESS [0.132s]
[INFO] Geronimo Plugins, JavaMail :: Core .................... SUCCESS [3.433s]
[INFO] Geronimo Plugins, JavaMail :: JavaMail ................ SUCCESS [3.954s]
[INFO] Geronimo Plugins, JAXWS :: Sun JAX-WS Tools ........... SUCCESS [2.215s]
[INFO] Geronimo Plugins, JAXWS :: Sun Tools .................. SUCCESS [30.755s]
[INFO] Geronimo Plugins, JAXWS :: Tools ...................... SUCCESS [4.176s]
[INFO] Geronimo Plugins, MyFaces ............................. SUCCESS [0.183s]
[INFO] Geronimo Plugins, MyFaces :: Core ..................... SUCCESS [4.545s]
[INFO] Geronimo Plugins, MyFaces :: Builder .................. SUCCESS [4.985s]
[INFO] Geronimo Plugins, MyFaces :: MyFaces .................. SUCCESS [2.922s]
[INFO] Geronimo Plugins, MyFaces :: Deployer ................. SUCCESS [4.890s]
[INFO] Geronimo Plugins, OpenEJB :: Clustering over WADI ..... SUCCESS [14.752s]
[INFO] Geronimo Plugins, OpenEJB :: Clustering over WADI ..... SUCCESS [7.037s]
[INFO] Geronimo Plugins, OpenEJB :: Clustering Builder for WADI
SUCCESS [7.263s]
[INFO] Geronimo Plugins, OpenEJB :: OpenEJB Client ........... SUCCESS [4.245s]
[INFO] Geronimo Plugins, OpenEJB :: Portlets ................. SUCCESS [4.778s]
[INFO] Geronimo Plugins, OpenEJB :: Jetty .................... SUCCESS [6.411s]
[INFO] Geronimo Plugins, OpenEJB :: Tomcat ................... SUCCESS [5.875s]
[INFO] Geronimo Plugins, OpenEJB :: Clustering Builder for WADI
SUCCESS [12.842s]
[INFO] Geronimo Plugins, OpenJPA2 :: Persistence 2.0 Builder . SUCCESS [2.171s]
[INFO] Geronimo Plugins, OpenJPA2 :: Deployer ................ SUCCESS [4.489s]
[INFO] Geronimo Plugins, OpenWebBeans :: Builder ............. SUCCESS [4.288s]
[INFO] Geronimo Plugins, OpenWebBeans :: Deployer ............ SUCCESS [8.537s]
[INFO] Geronimo Plugins, Wink ................................ SUCCESS [0.108s]
[INFO] Geronimo Plugins, Wink :: Core ........................ SUCCESS [27.497s]
[INFO] Geronimo Plugins, wink :: Builder ..................... SUCCESS [5.074s]
[INFO] Geronimo Plugins, wink :: wink ........................ SUCCESS [2.092s]
[INFO] Geronimo Plugins, wink :: Deployer .................... SUCCESS [4.149s]
[INFO] Geronimo Plugins, Plan Creator ........................ SUCCESS [0.129s]
[INFO] Geronimo Plugins, Plan Creator :: Portlets ............ SUCCESS [7.771s]
[INFO] Geronimo Plugins, Console :: Plan Creator (Jetty) ..... SUCCESS [11.677s]
[INFO] Geronimo Plugins, Console :: Plan Creator (Tomcat) .... SUCCESS [16.219s]
[INFO] Geronimo Plugins, UDDI ................................ SUCCESS [0.204s]
[INFO] Geronimo Plugins, UDDI : Database ..................... SUCCESS [20.668s]
[INFO] Geronimo Plugins, UDDI :: uddi-war-repackage .......... SUCCESS
[3:05.215s]
[INFO] Geronimo Plugins, UDDI Server :: Jetty ................ SUCCESS [8.757s]
[INFO] Geronimo Plugins, UDDI Server :: Tomcat ............... SUCCESS [48.946s]
[INFO] Geronimo Plugins, MEJB ................................ SUCCESS [0.152s]
[INFO] Geronimo Plugins, MEJB :: Core ........................ SUCCESS [1.734s]
[INFO] Geronimo Plugins, MEJB :: Config ...................... SUCCESS [5.438s]
[INFO] Geronimo Plugins, Remote Deploy ....................... SUCCESS [0.098s]
[INFO] Geronimo Plugins, Remote Deploy :: Core ............... SUCCESS [2.060s]
[INFO] Geronimo Plugins, Remote Deploy :: Jetty .............. SUCCESS [4.212s]
[INFO] Geronimo Plugins, Remote Deploy :: Tomcat ............. SUCCESS [4.780s]
[INFO] Geronimo Plugins, Welcome ............................. SUCCESS [0.366s]
[INFO] Geronimo Plugins, Welcome :: Core ..................... SUCCESS [2.248s]
[INFO] Geronimo Plugins, Welcome :: Jetty .................... SUCCESS [5.551s]
[INFO] Geronimo Plugins, Welcome :: Tomcat ................... SUCCESS [4.604s]
[INFO] Geronimo Plugins, Windows Service Wrapper ............. SUCCESS [1.224s]
[INFO] Geronimo Plugins, Jetty 8 :: Clustering over WADI Core SUCCESS [3.669s]
[INFO] Geronimo Plugins, Jetty 8 :: Clustering Builder for WADI Core
SUCCESS [12.479s]
[INFO] Geronimo Plugins, Jetty :: Jetty 8 Clustering over WADI
SUCCESS [10.915s]
[INFO] Geronimo Plugins, Jetty :: Clustering Builder for WADI SUCCESS [5.534s]
[INFO] Geronimo Plugins, Tomcat :: Tomcat without HA ......... SUCCESS [2.530s]
[INFO] Geronimo Plugins, Tomcat :: Clustering over WADI Core . SUCCESS [5.069s]
[INFO] Geronimo Plugins, Tomcat :: Clustering over WADI ...... SUCCESS [6.970s]
[INFO] Geronimo Plugins, Tomcat :: Clustering Builder for WADI Core
SUCCESS [8.049s]
[INFO] Geronimo Plugins, Tomcat :: Clustering Builder for WADI SUCCESS [6.369s]
[INFO] Geronimo Plugins, Aries ............................... SUCCESS [0.192s]
[INFO] Geronimo Plugins, Aries :: Core ....................... SUCCESS [10.657s]
[INFO] Geronimo Plugins, Aries :: Aries ...................... SUCCESS [21.879s]
[INFO] Geronimo Plugins, Aries :: Builder .................... SUCCESS [2.036s]
[INFO] Geronimo Plugins, Aries :: Shell ...................... SUCCESS [3.746s]
[INFO] Geronimo Plugins, Aries :: Deployer ................... SUCCESS [7.380s]
[INFO] Geronimo Plugins, WAB :: Web Extender ................. SUCCESS [2.507s]
[INFO] Geronimo Plugins, WAB :: Web Extender Plugin .......... SUCCESS [15.213s]
[INFO] Geronimo Plugin Groups ................................ SUCCESS [0.095s]
[INFO] Geronimo Plugin Group :: WAB Tomcat ................... SUCCESS [10.110s]
[INFO] Geronimo Plugin Group :: WAB Jetty .................... SUCCESS [15.529s]
[INFO] Geronimo Plugin Group :: JMS (ActiveMQ) ............... SUCCESS [7.820s]
[INFO] Geronimo Plugin Group :: Persistence .................. SUCCESS [10.765s]
[INFO] Geronimo Plugin Group :: EBA Tomcat ................... SUCCESS [32.299s]
[INFO] Geronimo Plugin Group :: EBA Jetty .................... SUCCESS [14.734s]
[INFO] Geronimo Plugin Group :: EJB .......................... SUCCESS [14.469s]
[INFO] Geronimo Plugin Group :: Console Jetty ................ SUCCESS [18.261s]
[INFO] Geronimo Plugin Group :: Java EE 6 Web Profile Jetty .. SUCCESS [19.017s]
[INFO] Geronimo Plugin Group :: Console Tomcat ............... SUCCESS [15.438s]
[INFO] Geronimo Plugin Group :: Java EE 6 Web Profile Tomcat . SUCCESS [2.851s]
[INFO] Geronimo Plugin Group :: Client ....................... SUCCESS [1.863s]
[INFO] Geronimo Plugin Group :: Web Services Axis2 ........... SUCCESS [2.673s]
[INFO] Geronimo Plugin Group :: Java EE 6 Jetty .............. SUCCESS [3.975s]
[INFO] Geronimo Plugin Group :: Java EE 6 Tomcat ............. SUCCESS [3.932s]
[INFO] Geronimo Assemblies ................................... SUCCESS [0.844s]
[INFO] Geronimo Assemblies :: Minimal + Jetty8 ............... SUCCESS [11.773s]
[INFO] Geronimo Assemblies :: Java EE 6 Web Profile + Jetty8 . SUCCESS [27.425s]
[INFO] Geronimo Assemblies :: Java EE 6 + Jetty8 ............. SUCCESS [39.986s]
[INFO] Geronimo Assemblies :: Minimal + Tomcat7 .............. SUCCESS [20.612s]
[INFO] Geronimo Assemblies :: Java EE 6 Web Profile + Tomcat7 SUCCESS [25.802s]
[INFO] Geronimo Assemblies :: Java EE 6 + Tomcat7 ............ SUCCESS [40.046s]
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 50 minutes 35 seconds
[INFO] Finished at: Thu Jun 23 01:08:56 CST 2011
[INFO] Final Memory: 683M/907M
[INFO] ------------------------------------------------------------------------
2011/6/23 Russell E Glaue <rg...@cait.org>
> On 06/22/2011 01:54 PM, Kevan Miller wrote:
> >
> > On Jun 22, 2011, at 1:27 PM, Russell E Glaue wrote:
> >
> >> On 06/22/2011 12:02 PM, Kevan Miller wrote:
> >>>
> >>> On Jun 22, 2011, at 12:09 PM, Russell E Glaue wrote:
> >
> > <snip>
> >
> >>>
> >>>>
> >>>> I am using a very basic build procedure.
> >>>> 1. checkout G3 trunk
> >>>> 2. JAVA_HOME="/path/to/jdk/1.6.0_22"
> >>>> 3. download and install a fresh maven 2.2.1
> >>>> 4. MAVEN_OPTS="-Xmx968m -XX:MaxPermSize=500m
> -XX:ReservedCodeCacheSize=64m"
> >>>
> >>> My settings are similar. I don't specify
> '-XX:ReservedCodeCacheSize=64m'.
> >>>
> >>> I run with the following. I know there are others running with larger
> max heaps. I haven't :
> >>>
> >>> MAVEN_OPTS="-Xmx1024m -XX:MaxPermSize=512m
> -XX:+HeapDumpOnOutOfMemoryError"
>
> Without the "-XX:ReservedCodeCacheSize=64m" option in MAVEN_OPTS I get this
> OutOfMemory error:
> -
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Building Geronimo Build Support :: Plugin 3.0-SNAPSHOT
> [INFO]
> ------------------------------------------------------------------------
> ...<snip>...
> [INFO] --- maven-compiler-plugin:2.0.2:compile (default-compile) @
> buildsupport-maven-plugin ---
> [INFO] Compiling 3 source files to
>
> /data/geronimo/asf-geronimo-server-trunk/framework/buildsupport/buildsupport-maven-plugin/target/classes
> [INFO]
> [INFO] --- gmaven-plugin:1.2:compile (default) @ buildsupport-maven-plugin
> ---
> ---------------------------------------------------
> constituent[0]:
> file:/usr/local/apache-maven-3.0.3/lib/maven-embedder-3.0.3.jar
> ...<snip>...
> constituent[30]:
> file:/usr/local/apache-maven-3.0.3/lib/maven-compat-3.0.3.jar
> ---------------------------------------------------
> Exception in thread "main" java.lang.VirtualMachineError: out of space in
> CodeCache for adapters
> at
>
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:212)
> at
>
> org.codehaus.groovy.ast.builder.AstBuilderTransformation.visit(AstBuilderTransformation.groovy:62)
> at
>
> org.codehaus.groovy.transform.ASTTransformationVisitor$3.call(ASTTransformationVisitor.java:268)
> at
>
> org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:799)
> at
>
> org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:464)
> at
>
> org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:443)
> at
>
> org.codehaus.gmaven.runtime.v1_6.ClassCompilerFeature$ClassCompilerImpl.compile(ClassCompilerFeature.java:159)
> at
>
> org.codehaus.gmaven.plugin.compile.AbstractCompileMojo.compile(AbstractCompileMojo.java:200)
> at
>
> org.codehaus.gmaven.plugin.compile.AbstractCompileMojo.process(AbstractCompileMojo.java:164)
> at
>
> org.codehaus.gmaven.plugin.ComponentMojoSupport.doExecute(ComponentMojoSupport.java:60)
> at
> org.codehaus.gmaven.plugin.MojoSupport.execute(MojoSupport.java:69)
> at
>
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at
>
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> at
>
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> -
>
> With the "-XX:ReservedCodeCacheSize=64m" flag, I do not get this error.
>
>
> >>
> >> The server I am build on has 1024MB of memory total, and has a dual
> dual-core
> >> Intel(R) XEON(TM) CPU 2.00GHz with 512KB cache.
> >>
> >> I have tried many JVM configurations, and the one like mine and yours is
> the
> >> best one I have found. For me, a JVM configuration with less than 400m
> for
> >> MaxPermSize always ended with an OutOfMemory error on PermGen space.
> >>
> >> The Geronimo dev wiki suggests 200m for MaxPermSize, which never worked
> for me
> >> for trunk. I always assumed it was because of all the snapshot
> downloading the
> >> build process has to do. Even after the 2nd or 3rd build, 200m was never
> enough.
> >
> > Right. So, MaxPermSize=200m is definitely out-of-date. There is/may be
> some bugs that are increasing this value. However, not really worth our
> while to pursue at the moment. I don't think MaxPermSize=500m is too
> prohibitive. More important things to do, ATM.
> >
> > That said -- I'm building on a machine with 8 gigs of real memory. So,
> 1024MB of real memory seems very small to me. And I suspect that this is the
> source of your problem... A max heap of 1024MB and MaxPermSize of 512m means
> your system may be spending a lot of time swapping virtual memory.
>
> So wrote what are your JVM Options set at:
> MAVEN_OPTS="-Xmx1024m -XX:MaxPermSize=512m
> -XX:+HeapDumpOnOutOfMemoryError"
> Mine are:
> MAVEN_OPTS="-Xmx968m -XX:MaxPermSize=500m -XX:ReservedCodeCacheSize=64m"
>
> The machine I am using has 1024MB of real memory and is dedicated to
> building
> geronimo (and it is not a virtual server). I set the heap max to 968m to
> keep
> the memory usage from peaking at 100% of system capacity.
>
> But there is a chance you may be right about the swaping. the machine runs
> at
> 100% real memory usage (expected) and about ~50% swap.
>
>
> I thinking recommending a minimum amount of real memory a machine should
> have to
> adequately compile G3 in a reasonable amount of time should be suggested.
> What would you say the minimum recommendation should be? For Windows and
> Linux?
> 2GB for Windows and 1.5GB for Linux, assuming the machine is dedicated to
> compiling?
>
> >
> >>
> >>>
> >>>> 5. mvn clean install
> >>>> 6. 13 to 39 hours later == BUILD SUCCESS
> >>>>
> >>>>
> >>>> From observing the build process, it would seem the most used
> (seemingly paused)
> >>>> time is right before the build process moves on to the next plugin or
> assembly.
> >>>>
> >>>> This "seemingly paused time" after the assembly I assume is the
> packaging
> >>>> process, because the resulting output is a huge collection.
> >>>>
> >>>> [INFO] Geronimo Assemblies ............................... SUCCESS
> [3.995s]
> >>>> [INFO] Geronimo Assemblies :: Minimal + Jetty8 ........... SUCCESS
> [8:15.210s]
> >>>> [INFO] Geronimo Assemblies :: Java EE 6 Web Profile + Jetty8 SUCCESS
> [1:57:17.311s]
> >>>> [INFO] Geronimo Assemblies :: Java EE 6 + Jetty8 ......... SUCCESS
> [1:02:47.374s]
> >>>> [INFO] Geronimo Assemblies :: Minimal + Tomcat7 .......... SUCCESS
> [8:08.838s]
> >>>> [INFO] Geronimo Assemblies :: Java EE 6 Web Profile + Tomcat7 SUCCESS
> >>>> [1:59:16.619s]
> >>>> [INFO] Geronimo Assemblies :: Java EE 6 + Tomcat7 ........ SUCCESS
> [1:08:13.854s]
> >>>>
> >>>> That is ~1.5 hours for the "Java EE 6 Web Profile + Jetty8" and "Java
> EE 6 Web
> >>>> Profile + Tomcat7" assemblies.
> >>>
> >>> Here are my build times. This is running without tests. Which would
> affect the overall build time. Assembly times would be unaffected -- we
> don't run any tests when building assemblies.
> >>>
> >>> [INFO] Geronimo Assemblies ............................... SUCCESS
> [0.163s]
> >>> [INFO] Geronimo Assemblies :: Minimal + Jetty8 ........... SUCCESS
> [42.253s]
> >>> [INFO] Geronimo Assemblies :: Java EE 6 Web Profile + Jetty8 SUCCESS
> [1:04.295s]
> >>> [INFO] Geronimo Assemblies :: Java EE 6 + Jetty8 ......... SUCCESS
> [1:33.097s]
> >>> [INFO] Geronimo Assemblies :: Minimal + Tomcat7 .......... SUCCESS
> [41.587s]
> >>> [INFO] Geronimo Assemblies :: Java EE 6 Web Profile + Tomcat7 SUCCESS
> [1:14.409s]
> >>> [INFO] Geronimo Assemblies :: Java EE 6 + Tomcat7 ........ SUCCESS
> [1:46.333s]
> >>> [INFO]
> ------------------------------------------------------------------------
> >>> [INFO] BUILD SUCCESS
> >>> [INFO]
> ------------------------------------------------------------------------
> >>> [INFO] Total time: 28:15.199s
> >>> [INFO] Finished at: Wed Jun 22 12:38:10 EDT 2011
> >>> [INFO] Final Memory: 633M/1011M
> >>> [INFO]
> ------------------------------------------------------------------------
> >>
> >> Yours is about 1/3 faster than mine.
> >
> > I think you've missed the metric. My times are an order of magnitude
> (hours vs minutes) better than yours.
> >
> >>>> [INFO] Geronimo Assemblies :: Java EE 6 + Tomcat7 ........ SUCCESS
> [1:08:13.854s]
> >
> > and
> >
> >>> [INFO] Geronimo Assemblies :: Java EE 6 + Tomcat7 ........ SUCCESS
> [1:46.333s]
> >
> > That's 68 minutes vs 1 minute 46 seconds. My *total* build time was 28
> minutes.
>
> Oh. ya. Let me rub my eyes and take another look there.... your right!
>
> >
> >> But you might have a faster processor too.
> >> Obviously, this part of the build is not the time consumer for me. It is
> nice to
> >> know this part of the build is supposed to take several hours - that
> helps me
> >> narrow down the issues.
>
> Okay - this was an incorrect statement by me.
>
> >>
> >>>
> >>>
> >>>>
> >>>>
> >>>> For the plugins, I would assume the same, except that I notice that,
> of course,
> >>>> the latest snapshot dependencies are being downloaded, and the poms in
> the maven
> >>>> SNAPSHOT repositories are continually being accessed.
> >>>>
> >>>> I realize that because trunk (G3) largely depends on 3rd-party
> artifact
> >>>> SNAPSHOTS that these repositories are checked during every build, and
> new
> >>>> SNAPSHOT libraries are always being downloaded (as is the nature of
> snapshot
> >>>> releases).
> >>>
> >>> Correct. A local maven proxy (e.g. Nexus) can reduce the overhead.
> >>
> >> So it is worth noting as it already is now.
> >>
> >>>
> >>>>
> >>>> As it is not a simple process for a user to setup a maven repo proxy,
> and could
> >>>> be a deterrent to someone getting started if it were necessary to
> install a
> >>>> proxy, I am looking at other methods and tips that might increase the
> speed of
> >>>> building G3.
> >>>
> >>> I've tried running with a local maven proxy. However, I've found it to
> be too much trouble to maintain/configure.
> >>
> >> Agreed. At least it is too much trouble if you are not continuously
> building the
> >> entire trunk every day on the larger scale. So too much to ask a G3
> beginner to do.
> >
> > Too much to ask of a new maven user -- I agree.
> >
> >>
> >>>
> >>>>
> >>>> Is this feasible? Or would we just say, that because of the nature of
> SNAPSHOT
> >>>> builds and their dependencies on 3rd-party SNAPSHOT artifacts, there
> is no real
> >>>> means to improving build speed unless a proxy is utilized?
> >>>> If the later is true, I would like to add this note in the wiki's
> build
> >>>> documentation. And also warn those who choose to build without a proxy
> may
> >>>> experience a long build time.
> >>>
> >>> While I'm thinking about it -- what is your network environment? The
> focus on proxies imply that your slow build times are predominantly network
> issue. Are you certain that is the case?
> >>
> >> We have about ~14Mb/s speed to the Internet. Our backplane is Gigabit
> Ethernet.
> >> We are connected to a major Internet backbone provider.
> >> I have been wondering if the problem is responsiveness of the maven repo
> sites.
> >> I have been seeing on occasion a refusal to download an artifact from
> the site,
> >> where as I was able to download it within a browser from the same URL.
> >> So I wonder if the repo sites are either metering the usage on a per
> user or
> >> session basis.
> >
> > I'm building on my home broadband connection. Probably similar speeds. I
> think we should identify the source of your extremely slow build time.
> >
> > If remote repository lookups are the cause of your problems, 'mvn -o
> clean install' should result in a much faster build time. However, I suspect
> that it won't make much difference at all...
>
> It seems a lot of "pauses" in the build process (while using the
> '-DskipTests=true' flag) is at the end of building each plugin, and that
> looks
> like this (example plugin build output)...
> (Note: almost every plugin gives the log4j errors)
> -
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Building Geronimo Plugins, Corba :: Deployer 3.0-SNAPSHOT
> [INFO]
> ------------------------------------------------------------------------
> [INFO]
> [INFO] --- maven-clean-plugin:2.3:clean (default-clean) @
> openejb-corba-deployer ---
> [INFO]
> [INFO] --- genesis-maven-plugin:2.0:validate-configuration (default) @
> openejb-corba-deployer ---
> [INFO]
> [INFO] --- geronimo-property-plugin:3.0-SNAPSHOT:set-property
> (set-property) @
> openejb-corba-deployer ---
> [INFO]
> [INFO] --- maven-enforcer-plugin:1.0-beta-1:enforce (default) @
> openejb-corba-deployer ---
> [INFO]
> [INFO] --- maven-remote-resources-plugin:1.0:process (default) @
> openejb-corba-deployer ---
>
> !!!!! somewhat of a pause here, can be up to 60 seconds sometimes !!!!!
>
> [WARNING] org.apache.velocity.runtime.exception.ReferenceException:
> reference :
> template = META-INF/DEPENDENCIES.vm [line 40,column 14] : $license.name is
> not a
> valid reference.
> [WARNING] org.apache.velocity.runtime.exception.ReferenceException:
> reference :
> template = META-INF/DEPENDENCIES.vm [line 40,column 14] : $license.name is
> not a
> valid reference.
> [INFO]
> [INFO] --- maven-resources-plugin:2.3:resources (default-resources) @
> openejb-corba-deployer ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory
>
> /data/geronimo/asf-geronimo-server-trunk/plugins/corba/openejb-corba-deployer/src/main/resources
> [INFO] skip non existing resourceDirectory
>
> /data/geronimo/asf-geronimo-server-trunk/plugins/corba/openejb-corba-deployer/src/main/filtered-resources
> [INFO] Copying 3 resources
>
> !!!!! for the plugins that use the maven-compiler-plugin:2.0.2:compile, of
> course this will take time as it is compiling !!!!!
> !!!!! However, the CPU usage only rises for like the first quarter of this
> wait
> time. !!!!!
>
> [INFO]
> [INFO] --- car-maven-plugin:3.0-SNAPSHOT:validate-configuration
> (default-validate-configuration) @ openejb-corba-deployer ---
> [INFO]
> [INFO] --- car-maven-plugin:3.0-SNAPSHOT:prepare-plan
> (default-prepare-plan) @
> openejb-corba-deployer ---
> [INFO] Generated:
>
> /data/geronimo/asf-geronimo-server-trunk/plugins/corba/openejb-corba-deployer/target/work/plan.xml
> [INFO]
> [INFO] --- car-maven-plugin:3.0-SNAPSHOT:verify-no-dependency-change
> (default-verify-no-dependency-change) @ openejb-corba-deployer ---
> [INFO]
> [INFO] --- car-maven-plugin:3.0-SNAPSHOT:prepare-metadata
> (default-prepare-metadata) @ openejb-corba-deployer ---
> [INFO]
> [INFO] --- car-maven-plugin:3.0-SNAPSHOT:package (default-package) @
> openejb-corba-deployer ---
> [INFO] Packaging module configuration:
>
> /data/geronimo/asf-geronimo-server-trunk/plugins/corba/openejb-corba-deployer/target/work/plan.xml
>
> org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator]
> : Enabling SLF4J API support.
>
> org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator]
> : Enabling Jakarta Commons Logging API support.
>
> org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator]
> : Enabling Log4J API support.
>
> org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator]
> : Enabling Avalon Logger API support.
>
> org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator]
> : Enabling JULI Logger API support.
> log4j:ERROR A "org.apache.log4j.ConsoleAppender" object is not assignable
> to a
> "org.apache.log4j.Appender" variable.
> log4j:ERROR The class "org.apache.log4j.Appender" was loaded by
> log4j:ERROR [25.0] whereas object of type
> log4j:ERROR "org.apache.log4j.ConsoleAppender" was loaded by
>
> [ClassRealm[plugin>org.apache.geronimo.buildsupport:car-maven-plugin:3.0-SNAPSHOT--1708152340,
> parent: sun.misc.Launcher$AppClassLoader@11b86e7]].
> log4j:ERROR Could not instantiate appender named "CONSOLE".
> log4j:ERROR A "org.apache.log4j.ConsoleAppender" object is not assignable
> to a
> "org.apache.log4j.Appender" variable.
> log4j:ERROR The class "org.apache.log4j.Appender" was loaded by
> log4j:ERROR [25.0] whereas object of type
> log4j:ERROR "org.apache.log4j.ConsoleAppender" was loaded by
>
> [ClassRealm[plugin>org.apache.geronimo.buildsupport:car-maven-plugin:3.0-SNAPSHOT--1708152340,
> parent: sun.misc.Launcher$AppClassLoader@11b86e7]].
> log4j:ERROR Could not instantiate appender named "A1".
> log4j:WARN No appenders could be found for logger
> (org.apache.geronimo.specs.geronimo-osgi-registry).
> log4j:WARN Please initialize the log4j system properly.
> log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for
> more info.
> log4j:ERROR A "org.apache.log4j.ConsoleAppender" object is not assignable
> to a
> "org.apache.log4j.Appender" variable.
> log4j:ERROR The class "org.apache.log4j.Appender" was loaded by
> log4j:ERROR [25.0] whereas object of type
> log4j:ERROR "org.apache.log4j.ConsoleAppender" was loaded by
>
> [ClassRealm[plugin>org.apache.geronimo.buildsupport:car-maven-plugin:3.0-SNAPSHOT--1708152340,
> parent: sun.misc.Launcher$AppClassLoader@11b86e7]].
> log4j:ERROR Could not instantiate appender named "A1".
>
> !!!!! always a significant pause here !!!!!
> !!!!! from a few minutes to several minutes !!!!!
>
> [INFO] Started deployer:
> org.apache.geronimo.framework/geronimo-gbean-deployer/3.0-SNAPSHOT/car
>
> !!!!! usually a significant pause here !!!!!
> !!!!! from less than a minute to a few minutes !!!!!
>
> [INFO]
> [INFO] --- car-maven-plugin:3.0-SNAPSHOT:archive-car (default-archive-car)
> @
> openejb-corba-deployer ---
>
> !!!!! seemingly always a significant pause here !!!!!
> !!!!! from a few minutes to 5-to-10 minutes !!!!!
>
>
> org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator]
> : Disabling SLF4J API support.
>
> org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator]
> : Disabling Jakarta Commons Logging API support.
>
> org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator]
> : Disabling Log4J API support.
>
> org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator]
> : Disabling Avalon Logger API support.
>
> org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator]
> : Disabling JULI Logger API support.
> [INFO] Expanding:
>
> /data/geronimo/asf-geronimo-server-trunk/plugins/corba/openejb-corba-deployer/target/repository/org/apache/geronimo/configs/openejb-corba-deployer/3.0-SNAPSHOT/openejb-corba-deployer-3.0-SNAPSHOT.car
> into /tmp/archived-file-set.516894452.tmp
> [INFO] Building jar:
>
> /data/geronimo/asf-geronimo-server-trunk/plugins/corba/openejb-corba-deployer/target/openejb-corba-deployer-3.0-SNAPSHOT.car
> [INFO] Building jar:
>
> /data/geronimo/asf-geronimo-server-trunk/plugins/corba/openejb-corba-deployer/target/openejb-corba-deployer-3.0-SNAPSHOT.car
> [INFO]
> [INFO] --- geronimo-osgi-plugin:3.0-SNAPSHOT:verify-manifest
> (verify-manifest) @
> openejb-corba-deployer ---
> [INFO]
> [INFO] --- ianal-maven-plugin:1.0-alpha-1:verify-legal-files (default) @
> openejb-corba-deployer ---
> [INFO] Checking legal files in: openejb-corba-deployer-3.0-SNAPSHOT.car
> [INFO]
> [INFO] --- maven-install-plugin:2.2:install (default-install) @
> openejb-corba-deployer ---
> [INFO] Installing
>
> /data/geronimo/asf-geronimo-server-trunk/plugins/corba/openejb-corba-deployer/target/openejb-corba-deployer-3.0-SNAPSHOT.car
> to
>
> /home/ger/.m2/repository/org/apache/geronimo/configs/openejb-corba-deployer/3.0-SNAPSHOT/openejb-corba-deployer-3.0-SNAPSHOT.car
> [INFO] Installing
>
> /data/geronimo/asf-geronimo-server-trunk/plugins/corba/openejb-corba-deployer/pom.xml
> to
>
> /home/ger/.m2/repository/org/apache/geronimo/configs/openejb-corba-deployer/3.0-SNAPSHOT/openejb-corba-deployer-3.0-SNAPSHOT.pom
> [INFO] Installing
>
> /data/geronimo/asf-geronimo-server-trunk/plugins/corba/openejb-corba-deployer/target/resources/META-INF/geronimo-plugin.xml
> to
>
> /home/ger/.m2/repository/org/apache/geronimo/configs/openejb-corba-deployer/3.0-SNAPSHOT/openejb-corba-deployer-3.0-SNAPSHOT.plugin-metadata
> [INFO]
> [INFO] --- car-maven-plugin:3.0-SNAPSHOT:update-pluginlist
> (default-update-pluginlist) @ openejb-corba-deployer ---
> [INFO]
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Building Geronimo Plugins, Corba :: Client Yoko 3.0-SNAPSHOT
> [INFO]
> ------------------------------------------------------------------------
> ... etc ...
> -
>
> >
> >>
> >> Thanks for the excellent tips!
> >> I'll try some things out, and look at how to reflect the tips in the
> wiki
> >> without degrading any affirmation of Best Practices (i.e. running the
> test cases
> >> is good).
> >
> > No problem. Many thanks for digging into this. Definitely an area we tend
> to overlook...
> >
> > --kevan
> >
>
--
Lei Wang (Rex)
rwonly AT apache.org
Re: Speeding up G3.0 build time
Posted by Russell E Glaue <rg...@cait.org>.
On 06/22/2011 01:54 PM, Kevan Miller wrote:
>
> On Jun 22, 2011, at 1:27 PM, Russell E Glaue wrote:
>
>> On 06/22/2011 12:02 PM, Kevan Miller wrote:
>>>
>>> On Jun 22, 2011, at 12:09 PM, Russell E Glaue wrote:
>
> <snip>
>
>>>
>>>>
>>>> I am using a very basic build procedure.
>>>> 1. checkout G3 trunk
>>>> 2. JAVA_HOME="/path/to/jdk/1.6.0_22"
>>>> 3. download and install a fresh maven 2.2.1
>>>> 4. MAVEN_OPTS="-Xmx968m -XX:MaxPermSize=500m -XX:ReservedCodeCacheSize=64m"
>>>
>>> My settings are similar. I don't specify '-XX:ReservedCodeCacheSize=64m'.
>>>
>>> I run with the following. I know there are others running with larger max heaps. I haven't :
>>>
>>> MAVEN_OPTS="-Xmx1024m -XX:MaxPermSize=512m -XX:+HeapDumpOnOutOfMemoryError"
Without the "-XX:ReservedCodeCacheSize=64m" option in MAVEN_OPTS I get this
OutOfMemory error:
-
[INFO] ------------------------------------------------------------------------
[INFO] Building Geronimo Build Support :: Plugin 3.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
...<snip>...
[INFO] --- maven-compiler-plugin:2.0.2:compile (default-compile) @
buildsupport-maven-plugin ---
[INFO] Compiling 3 source files to
/data/geronimo/asf-geronimo-server-trunk/framework/buildsupport/buildsupport-maven-plugin/target/classes
[INFO]
[INFO] --- gmaven-plugin:1.2:compile (default) @ buildsupport-maven-plugin ---
---------------------------------------------------
constituent[0]: file:/usr/local/apache-maven-3.0.3/lib/maven-embedder-3.0.3.jar
...<snip>...
constituent[30]: file:/usr/local/apache-maven-3.0.3/lib/maven-compat-3.0.3.jar
---------------------------------------------------
Exception in thread "main" java.lang.VirtualMachineError: out of space in
CodeCache for adapters
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:212)
at
org.codehaus.groovy.ast.builder.AstBuilderTransformation.visit(AstBuilderTransformation.groovy:62)
at
org.codehaus.groovy.transform.ASTTransformationVisitor$3.call(ASTTransformationVisitor.java:268)
at
org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:799)
at
org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:464)
at
org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:443)
at
org.codehaus.gmaven.runtime.v1_6.ClassCompilerFeature$ClassCompilerImpl.compile(ClassCompilerFeature.java:159)
at
org.codehaus.gmaven.plugin.compile.AbstractCompileMojo.compile(AbstractCompileMojo.java:200)
at
org.codehaus.gmaven.plugin.compile.AbstractCompileMojo.process(AbstractCompileMojo.java:164)
at
org.codehaus.gmaven.plugin.ComponentMojoSupport.doExecute(ComponentMojoSupport.java:60)
at org.codehaus.gmaven.plugin.MojoSupport.execute(MojoSupport.java:69)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
-
With the "-XX:ReservedCodeCacheSize=64m" flag, I do not get this error.
>>
>> The server I am build on has 1024MB of memory total, and has a dual dual-core
>> Intel(R) XEON(TM) CPU 2.00GHz with 512KB cache.
>>
>> I have tried many JVM configurations, and the one like mine and yours is the
>> best one I have found. For me, a JVM configuration with less than 400m for
>> MaxPermSize always ended with an OutOfMemory error on PermGen space.
>>
>> The Geronimo dev wiki suggests 200m for MaxPermSize, which never worked for me
>> for trunk. I always assumed it was because of all the snapshot downloading the
>> build process has to do. Even after the 2nd or 3rd build, 200m was never enough.
>
> Right. So, MaxPermSize=200m is definitely out-of-date. There is/may be some bugs that are increasing this value. However, not really worth our while to pursue at the moment. I don't think MaxPermSize=500m is too prohibitive. More important things to do, ATM.
>
> That said -- I'm building on a machine with 8 gigs of real memory. So, 1024MB of real memory seems very small to me. And I suspect that this is the source of your problem... A max heap of 1024MB and MaxPermSize of 512m means your system may be spending a lot of time swapping virtual memory.
So wrote what are your JVM Options set at:
MAVEN_OPTS="-Xmx1024m -XX:MaxPermSize=512m -XX:+HeapDumpOnOutOfMemoryError"
Mine are:
MAVEN_OPTS="-Xmx968m -XX:MaxPermSize=500m -XX:ReservedCodeCacheSize=64m"
The machine I am using has 1024MB of real memory and is dedicated to building
geronimo (and it is not a virtual server). I set the heap max to 968m to keep
the memory usage from peaking at 100% of system capacity.
But there is a chance you may be right about the swaping. the machine runs at
100% real memory usage (expected) and about ~50% swap.
I thinking recommending a minimum amount of real memory a machine should have to
adequately compile G3 in a reasonable amount of time should be suggested.
What would you say the minimum recommendation should be? For Windows and Linux?
2GB for Windows and 1.5GB for Linux, assuming the machine is dedicated to compiling?
>
>>
>>>
>>>> 5. mvn clean install
>>>> 6. 13 to 39 hours later == BUILD SUCCESS
>>>>
>>>>
>>>> From observing the build process, it would seem the most used (seemingly paused)
>>>> time is right before the build process moves on to the next plugin or assembly.
>>>>
>>>> This "seemingly paused time" after the assembly I assume is the packaging
>>>> process, because the resulting output is a huge collection.
>>>>
>>>> [INFO] Geronimo Assemblies ............................... SUCCESS [3.995s]
>>>> [INFO] Geronimo Assemblies :: Minimal + Jetty8 ........... SUCCESS [8:15.210s]
>>>> [INFO] Geronimo Assemblies :: Java EE 6 Web Profile + Jetty8 SUCCESS [1:57:17.311s]
>>>> [INFO] Geronimo Assemblies :: Java EE 6 + Jetty8 ......... SUCCESS [1:02:47.374s]
>>>> [INFO] Geronimo Assemblies :: Minimal + Tomcat7 .......... SUCCESS [8:08.838s]
>>>> [INFO] Geronimo Assemblies :: Java EE 6 Web Profile + Tomcat7 SUCCESS
>>>> [1:59:16.619s]
>>>> [INFO] Geronimo Assemblies :: Java EE 6 + Tomcat7 ........ SUCCESS [1:08:13.854s]
>>>>
>>>> That is ~1.5 hours for the "Java EE 6 Web Profile + Jetty8" and "Java EE 6 Web
>>>> Profile + Tomcat7" assemblies.
>>>
>>> Here are my build times. This is running without tests. Which would affect the overall build time. Assembly times would be unaffected -- we don't run any tests when building assemblies.
>>>
>>> [INFO] Geronimo Assemblies ............................... SUCCESS [0.163s]
>>> [INFO] Geronimo Assemblies :: Minimal + Jetty8 ........... SUCCESS [42.253s]
>>> [INFO] Geronimo Assemblies :: Java EE 6 Web Profile + Jetty8 SUCCESS [1:04.295s]
>>> [INFO] Geronimo Assemblies :: Java EE 6 + Jetty8 ......... SUCCESS [1:33.097s]
>>> [INFO] Geronimo Assemblies :: Minimal + Tomcat7 .......... SUCCESS [41.587s]
>>> [INFO] Geronimo Assemblies :: Java EE 6 Web Profile + Tomcat7 SUCCESS [1:14.409s]
>>> [INFO] Geronimo Assemblies :: Java EE 6 + Tomcat7 ........ SUCCESS [1:46.333s]
>>> [INFO] ------------------------------------------------------------------------
>>> [INFO] BUILD SUCCESS
>>> [INFO] ------------------------------------------------------------------------
>>> [INFO] Total time: 28:15.199s
>>> [INFO] Finished at: Wed Jun 22 12:38:10 EDT 2011
>>> [INFO] Final Memory: 633M/1011M
>>> [INFO] ------------------------------------------------------------------------
>>
>> Yours is about 1/3 faster than mine.
>
> I think you've missed the metric. My times are an order of magnitude (hours vs minutes) better than yours.
>
>>>> [INFO] Geronimo Assemblies :: Java EE 6 + Tomcat7 ........ SUCCESS [1:08:13.854s]
>
> and
>
>>> [INFO] Geronimo Assemblies :: Java EE 6 + Tomcat7 ........ SUCCESS [1:46.333s]
>
> That's 68 minutes vs 1 minute 46 seconds. My *total* build time was 28 minutes.
Oh. ya. Let me rub my eyes and take another look there.... your right!
>
>> But you might have a faster processor too.
>> Obviously, this part of the build is not the time consumer for me. It is nice to
>> know this part of the build is supposed to take several hours - that helps me
>> narrow down the issues.
Okay - this was an incorrect statement by me.
>>
>>>
>>>
>>>>
>>>>
>>>> For the plugins, I would assume the same, except that I notice that, of course,
>>>> the latest snapshot dependencies are being downloaded, and the poms in the maven
>>>> SNAPSHOT repositories are continually being accessed.
>>>>
>>>> I realize that because trunk (G3) largely depends on 3rd-party artifact
>>>> SNAPSHOTS that these repositories are checked during every build, and new
>>>> SNAPSHOT libraries are always being downloaded (as is the nature of snapshot
>>>> releases).
>>>
>>> Correct. A local maven proxy (e.g. Nexus) can reduce the overhead.
>>
>> So it is worth noting as it already is now.
>>
>>>
>>>>
>>>> As it is not a simple process for a user to setup a maven repo proxy, and could
>>>> be a deterrent to someone getting started if it were necessary to install a
>>>> proxy, I am looking at other methods and tips that might increase the speed of
>>>> building G3.
>>>
>>> I've tried running with a local maven proxy. However, I've found it to be too much trouble to maintain/configure.
>>
>> Agreed. At least it is too much trouble if you are not continuously building the
>> entire trunk every day on the larger scale. So too much to ask a G3 beginner to do.
>
> Too much to ask of a new maven user -- I agree.
>
>>
>>>
>>>>
>>>> Is this feasible? Or would we just say, that because of the nature of SNAPSHOT
>>>> builds and their dependencies on 3rd-party SNAPSHOT artifacts, there is no real
>>>> means to improving build speed unless a proxy is utilized?
>>>> If the later is true, I would like to add this note in the wiki's build
>>>> documentation. And also warn those who choose to build without a proxy may
>>>> experience a long build time.
>>>
>>> While I'm thinking about it -- what is your network environment? The focus on proxies imply that your slow build times are predominantly network issue. Are you certain that is the case?
>>
>> We have about ~14Mb/s speed to the Internet. Our backplane is Gigabit Ethernet.
>> We are connected to a major Internet backbone provider.
>> I have been wondering if the problem is responsiveness of the maven repo sites.
>> I have been seeing on occasion a refusal to download an artifact from the site,
>> where as I was able to download it within a browser from the same URL.
>> So I wonder if the repo sites are either metering the usage on a per user or
>> session basis.
>
> I'm building on my home broadband connection. Probably similar speeds. I think we should identify the source of your extremely slow build time.
>
> If remote repository lookups are the cause of your problems, 'mvn -o clean install' should result in a much faster build time. However, I suspect that it won't make much difference at all...
It seems a lot of "pauses" in the build process (while using the
'-DskipTests=true' flag) is at the end of building each plugin, and that looks
like this (example plugin build output)...
(Note: almost every plugin gives the log4j errors)
-
[INFO] ------------------------------------------------------------------------
[INFO] Building Geronimo Plugins, Corba :: Deployer 3.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-clean-plugin:2.3:clean (default-clean) @ openejb-corba-deployer ---
[INFO]
[INFO] --- genesis-maven-plugin:2.0:validate-configuration (default) @
openejb-corba-deployer ---
[INFO]
[INFO] --- geronimo-property-plugin:3.0-SNAPSHOT:set-property (set-property) @
openejb-corba-deployer ---
[INFO]
[INFO] --- maven-enforcer-plugin:1.0-beta-1:enforce (default) @
openejb-corba-deployer ---
[INFO]
[INFO] --- maven-remote-resources-plugin:1.0:process (default) @
openejb-corba-deployer ---
!!!!! somewhat of a pause here, can be up to 60 seconds sometimes !!!!!
[WARNING] org.apache.velocity.runtime.exception.ReferenceException: reference :
template = META-INF/DEPENDENCIES.vm [line 40,column 14] : $license.name is not a
valid reference.
[WARNING] org.apache.velocity.runtime.exception.ReferenceException: reference :
template = META-INF/DEPENDENCIES.vm [line 40,column 14] : $license.name is not a
valid reference.
[INFO]
[INFO] --- maven-resources-plugin:2.3:resources (default-resources) @
openejb-corba-deployer ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
/data/geronimo/asf-geronimo-server-trunk/plugins/corba/openejb-corba-deployer/src/main/resources
[INFO] skip non existing resourceDirectory
/data/geronimo/asf-geronimo-server-trunk/plugins/corba/openejb-corba-deployer/src/main/filtered-resources
[INFO] Copying 3 resources
!!!!! for the plugins that use the maven-compiler-plugin:2.0.2:compile, of
course this will take time as it is compiling !!!!!
!!!!! However, the CPU usage only rises for like the first quarter of this wait
time. !!!!!
[INFO]
[INFO] --- car-maven-plugin:3.0-SNAPSHOT:validate-configuration
(default-validate-configuration) @ openejb-corba-deployer ---
[INFO]
[INFO] --- car-maven-plugin:3.0-SNAPSHOT:prepare-plan (default-prepare-plan) @
openejb-corba-deployer ---
[INFO] Generated:
/data/geronimo/asf-geronimo-server-trunk/plugins/corba/openejb-corba-deployer/target/work/plan.xml
[INFO]
[INFO] --- car-maven-plugin:3.0-SNAPSHOT:verify-no-dependency-change
(default-verify-no-dependency-change) @ openejb-corba-deployer ---
[INFO]
[INFO] --- car-maven-plugin:3.0-SNAPSHOT:prepare-metadata
(default-prepare-metadata) @ openejb-corba-deployer ---
[INFO]
[INFO] --- car-maven-plugin:3.0-SNAPSHOT:package (default-package) @
openejb-corba-deployer ---
[INFO] Packaging module configuration:
/data/geronimo/asf-geronimo-server-trunk/plugins/corba/openejb-corba-deployer/target/work/plan.xml
org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator]
: Enabling SLF4J API support.
org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator]
: Enabling Jakarta Commons Logging API support.
org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator]
: Enabling Log4J API support.
org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator]
: Enabling Avalon Logger API support.
org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator]
: Enabling JULI Logger API support.
log4j:ERROR A "org.apache.log4j.ConsoleAppender" object is not assignable to a
"org.apache.log4j.Appender" variable.
log4j:ERROR The class "org.apache.log4j.Appender" was loaded by
log4j:ERROR [25.0] whereas object of type
log4j:ERROR "org.apache.log4j.ConsoleAppender" was loaded by
[ClassRealm[plugin>org.apache.geronimo.buildsupport:car-maven-plugin:3.0-SNAPSHOT--1708152340,
parent: sun.misc.Launcher$AppClassLoader@11b86e7]].
log4j:ERROR Could not instantiate appender named "CONSOLE".
log4j:ERROR A "org.apache.log4j.ConsoleAppender" object is not assignable to a
"org.apache.log4j.Appender" variable.
log4j:ERROR The class "org.apache.log4j.Appender" was loaded by
log4j:ERROR [25.0] whereas object of type
log4j:ERROR "org.apache.log4j.ConsoleAppender" was loaded by
[ClassRealm[plugin>org.apache.geronimo.buildsupport:car-maven-plugin:3.0-SNAPSHOT--1708152340,
parent: sun.misc.Launcher$AppClassLoader@11b86e7]].
log4j:ERROR Could not instantiate appender named "A1".
log4j:WARN No appenders could be found for logger
(org.apache.geronimo.specs.geronimo-osgi-registry).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
log4j:ERROR A "org.apache.log4j.ConsoleAppender" object is not assignable to a
"org.apache.log4j.Appender" variable.
log4j:ERROR The class "org.apache.log4j.Appender" was loaded by
log4j:ERROR [25.0] whereas object of type
log4j:ERROR "org.apache.log4j.ConsoleAppender" was loaded by
[ClassRealm[plugin>org.apache.geronimo.buildsupport:car-maven-plugin:3.0-SNAPSHOT--1708152340,
parent: sun.misc.Launcher$AppClassLoader@11b86e7]].
log4j:ERROR Could not instantiate appender named "A1".
!!!!! always a significant pause here !!!!!
!!!!! from a few minutes to several minutes !!!!!
[INFO] Started deployer:
org.apache.geronimo.framework/geronimo-gbean-deployer/3.0-SNAPSHOT/car
!!!!! usually a significant pause here !!!!!
!!!!! from less than a minute to a few minutes !!!!!
[INFO]
[INFO] --- car-maven-plugin:3.0-SNAPSHOT:archive-car (default-archive-car) @
openejb-corba-deployer ---
!!!!! seemingly always a significant pause here !!!!!
!!!!! from a few minutes to 5-to-10 minutes !!!!!
org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator]
: Disabling SLF4J API support.
org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator]
: Disabling Jakarta Commons Logging API support.
org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator]
: Disabling Log4J API support.
org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator]
: Disabling Avalon Logger API support.
org.ops4j.pax.logging.pax-logging-api[org.ops4j.pax.logging.internal.Activator]
: Disabling JULI Logger API support.
[INFO] Expanding:
/data/geronimo/asf-geronimo-server-trunk/plugins/corba/openejb-corba-deployer/target/repository/org/apache/geronimo/configs/openejb-corba-deployer/3.0-SNAPSHOT/openejb-corba-deployer-3.0-SNAPSHOT.car
into /tmp/archived-file-set.516894452.tmp
[INFO] Building jar:
/data/geronimo/asf-geronimo-server-trunk/plugins/corba/openejb-corba-deployer/target/openejb-corba-deployer-3.0-SNAPSHOT.car
[INFO] Building jar:
/data/geronimo/asf-geronimo-server-trunk/plugins/corba/openejb-corba-deployer/target/openejb-corba-deployer-3.0-SNAPSHOT.car
[INFO]
[INFO] --- geronimo-osgi-plugin:3.0-SNAPSHOT:verify-manifest (verify-manifest) @
openejb-corba-deployer ---
[INFO]
[INFO] --- ianal-maven-plugin:1.0-alpha-1:verify-legal-files (default) @
openejb-corba-deployer ---
[INFO] Checking legal files in: openejb-corba-deployer-3.0-SNAPSHOT.car
[INFO]
[INFO] --- maven-install-plugin:2.2:install (default-install) @
openejb-corba-deployer ---
[INFO] Installing
/data/geronimo/asf-geronimo-server-trunk/plugins/corba/openejb-corba-deployer/target/openejb-corba-deployer-3.0-SNAPSHOT.car
to
/home/ger/.m2/repository/org/apache/geronimo/configs/openejb-corba-deployer/3.0-SNAPSHOT/openejb-corba-deployer-3.0-SNAPSHOT.car
[INFO] Installing
/data/geronimo/asf-geronimo-server-trunk/plugins/corba/openejb-corba-deployer/pom.xml
to
/home/ger/.m2/repository/org/apache/geronimo/configs/openejb-corba-deployer/3.0-SNAPSHOT/openejb-corba-deployer-3.0-SNAPSHOT.pom
[INFO] Installing
/data/geronimo/asf-geronimo-server-trunk/plugins/corba/openejb-corba-deployer/target/resources/META-INF/geronimo-plugin.xml
to
/home/ger/.m2/repository/org/apache/geronimo/configs/openejb-corba-deployer/3.0-SNAPSHOT/openejb-corba-deployer-3.0-SNAPSHOT.plugin-metadata
[INFO]
[INFO] --- car-maven-plugin:3.0-SNAPSHOT:update-pluginlist
(default-update-pluginlist) @ openejb-corba-deployer ---
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building Geronimo Plugins, Corba :: Client Yoko 3.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
... etc ...
-
>
>>
>> Thanks for the excellent tips!
>> I'll try some things out, and look at how to reflect the tips in the wiki
>> without degrading any affirmation of Best Practices (i.e. running the test cases
>> is good).
>
> No problem. Many thanks for digging into this. Definitely an area we tend to overlook...
>
> --kevan
>
Re: Speeding up G3.0 build time
Posted by Kevan Miller <ke...@gmail.com>.
On Jun 22, 2011, at 1:27 PM, Russell E Glaue wrote:
> On 06/22/2011 12:02 PM, Kevan Miller wrote:
>>
>> On Jun 22, 2011, at 12:09 PM, Russell E Glaue wrote:
<snip>
>>
>>>
>>> I am using a very basic build procedure.
>>> 1. checkout G3 trunk
>>> 2. JAVA_HOME="/path/to/jdk/1.6.0_22"
>>> 3. download and install a fresh maven 2.2.1
>>> 4. MAVEN_OPTS="-Xmx968m -XX:MaxPermSize=500m -XX:ReservedCodeCacheSize=64m"
>>
>> My settings are similar. I don't specify '-XX:ReservedCodeCacheSize=64m'.
>>
>> I run with the following. I know there are others running with larger max heaps. I haven't :
>>
>> MAVEN_OPTS="-Xmx1024m -XX:MaxPermSize=512m -XX:+HeapDumpOnOutOfMemoryError"
>
> The server I am build on has 1024MB of memory total, and has a dual dual-core
> Intel(R) XEON(TM) CPU 2.00GHz with 512KB cache.
>
> I have tried many JVM configurations, and the one like mine and yours is the
> best one I have found. For me, a JVM configuration with less than 400m for
> MaxPermSize always ended with an OutOfMemory error on PermGen space.
>
> The Geronimo dev wiki suggests 200m for MaxPermSize, which never worked for me
> for trunk. I always assumed it was because of all the snapshot downloading the
> build process has to do. Even after the 2nd or 3rd build, 200m was never enough.
Right. So, MaxPermSize=200m is definitely out-of-date. There is/may be some bugs that are increasing this value. However, not really worth our while to pursue at the moment. I don't think MaxPermSize=500m is too prohibitive. More important things to do, ATM.
That said -- I'm building on a machine with 8 gigs of real memory. So, 1024MB of real memory seems very small to me. And I suspect that this is the source of your problem... A max heap of 1024MB and MaxPermSize of 512m means your system may be spending a lot of time swapping virtual memory.
>
>>
>>> 5. mvn clean install
>>> 6. 13 to 39 hours later == BUILD SUCCESS
>>>
>>>
>>> From observing the build process, it would seem the most used (seemingly paused)
>>> time is right before the build process moves on to the next plugin or assembly.
>>>
>>> This "seemingly paused time" after the assembly I assume is the packaging
>>> process, because the resulting output is a huge collection.
>>>
>>> [INFO] Geronimo Assemblies ............................... SUCCESS [3.995s]
>>> [INFO] Geronimo Assemblies :: Minimal + Jetty8 ........... SUCCESS [8:15.210s]
>>> [INFO] Geronimo Assemblies :: Java EE 6 Web Profile + Jetty8 SUCCESS [1:57:17.311s]
>>> [INFO] Geronimo Assemblies :: Java EE 6 + Jetty8 ......... SUCCESS [1:02:47.374s]
>>> [INFO] Geronimo Assemblies :: Minimal + Tomcat7 .......... SUCCESS [8:08.838s]
>>> [INFO] Geronimo Assemblies :: Java EE 6 Web Profile + Tomcat7 SUCCESS
>>> [1:59:16.619s]
>>> [INFO] Geronimo Assemblies :: Java EE 6 + Tomcat7 ........ SUCCESS [1:08:13.854s]
>>>
>>> That is ~1.5 hours for the "Java EE 6 Web Profile + Jetty8" and "Java EE 6 Web
>>> Profile + Tomcat7" assemblies.
>>
>> Here are my build times. This is running without tests. Which would affect the overall build time. Assembly times would be unaffected -- we don't run any tests when building assemblies.
>>
>> [INFO] Geronimo Assemblies ............................... SUCCESS [0.163s]
>> [INFO] Geronimo Assemblies :: Minimal + Jetty8 ........... SUCCESS [42.253s]
>> [INFO] Geronimo Assemblies :: Java EE 6 Web Profile + Jetty8 SUCCESS [1:04.295s]
>> [INFO] Geronimo Assemblies :: Java EE 6 + Jetty8 ......... SUCCESS [1:33.097s]
>> [INFO] Geronimo Assemblies :: Minimal + Tomcat7 .......... SUCCESS [41.587s]
>> [INFO] Geronimo Assemblies :: Java EE 6 Web Profile + Tomcat7 SUCCESS [1:14.409s]
>> [INFO] Geronimo Assemblies :: Java EE 6 + Tomcat7 ........ SUCCESS [1:46.333s]
>> [INFO] ------------------------------------------------------------------------
>> [INFO] BUILD SUCCESS
>> [INFO] ------------------------------------------------------------------------
>> [INFO] Total time: 28:15.199s
>> [INFO] Finished at: Wed Jun 22 12:38:10 EDT 2011
>> [INFO] Final Memory: 633M/1011M
>> [INFO] ------------------------------------------------------------------------
>
> Yours is about 1/3 faster than mine.
I think you've missed the metric. My times are an order of magnitude (hours vs minutes) better than yours.
>>> [INFO] Geronimo Assemblies :: Java EE 6 + Tomcat7 ........ SUCCESS [1:08:13.854s]
and
>> [INFO] Geronimo Assemblies :: Java EE 6 + Tomcat7 ........ SUCCESS [1:46.333s]
That's 68 minutes vs 1 minute 46 seconds. My *total* build time was 28 minutes.
> But you might have a faster processor too.
> Obviously, this part of the build is not the time consumer for me. It is nice to
> know this part of the build is supposed to take several hours - that helps me
> narrow down the issues.
>
>>
>>
>>>
>>>
>>> For the plugins, I would assume the same, except that I notice that, of course,
>>> the latest snapshot dependencies are being downloaded, and the poms in the maven
>>> SNAPSHOT repositories are continually being accessed.
>>>
>>> I realize that because trunk (G3) largely depends on 3rd-party artifact
>>> SNAPSHOTS that these repositories are checked during every build, and new
>>> SNAPSHOT libraries are always being downloaded (as is the nature of snapshot
>>> releases).
>>
>> Correct. A local maven proxy (e.g. Nexus) can reduce the overhead.
>
> So it is worth noting as it already is now.
>
>>
>>>
>>> As it is not a simple process for a user to setup a maven repo proxy, and could
>>> be a deterrent to someone getting started if it were necessary to install a
>>> proxy, I am looking at other methods and tips that might increase the speed of
>>> building G3.
>>
>> I've tried running with a local maven proxy. However, I've found it to be too much trouble to maintain/configure.
>
> Agreed. At least it is too much trouble if you are not continuously building the
> entire trunk every day on the larger scale. So too much to ask a G3 beginner to do.
Too much to ask of a new maven user -- I agree.
>
>>
>>>
>>> Is this feasible? Or would we just say, that because of the nature of SNAPSHOT
>>> builds and their dependencies on 3rd-party SNAPSHOT artifacts, there is no real
>>> means to improving build speed unless a proxy is utilized?
>>> If the later is true, I would like to add this note in the wiki's build
>>> documentation. And also warn those who choose to build without a proxy may
>>> experience a long build time.
>>
>> While I'm thinking about it -- what is your network environment? The focus on proxies imply that your slow build times are predominantly network issue. Are you certain that is the case?
>
> We have about ~14Mb/s speed to the Internet. Our backplane is Gigabit Ethernet.
> We are connected to a major Internet backbone provider.
> I have been wondering if the problem is responsiveness of the maven repo sites.
> I have been seeing on occasion a refusal to download an artifact from the site,
> where as I was able to download it within a browser from the same URL.
> So I wonder if the repo sites are either metering the usage on a per user or
> session basis.
I'm building on my home broadband connection. Probably similar speeds. I think we should identify the source of your extremely slow build time.
If remote repository lookups are the cause of your problems, 'mvn -o clean install' should result in a much faster build time. However, I suspect that it won't make much difference at all...
>
> Thanks for the excellent tips!
> I'll try some things out, and look at how to reflect the tips in the wiki
> without degrading any affirmation of Best Practices (i.e. running the test cases
> is good).
No problem. Many thanks for digging into this. Definitely an area we tend to overlook...
--kevan
Re: Speeding up G3.0 build time
Posted by Russell E Glaue <rg...@cait.org>.
On 06/22/2011 12:02 PM, Kevan Miller wrote:
>
> On Jun 22, 2011, at 12:09 PM, Russell E Glaue wrote:
>
>> I am wanting to update the G3 dev wiki to help first-time builders get started.
>> How would you suggest a build of G3 could become faster?
>>
>> The only tip I am aware of for speeding up trunk (G3) builds is to install a
>> maven repository proxy like nexus. This is eluded to in the wiki already.
>> Are there any other tips?
>
> You can build without tests. E.g.: 'mvn clean install -DskipTests=true'. If I'm simply running a build, I'll frequently turn off tests ('-DskipTests=true' I think '-DskipTests' is equivalent). If I'm making code changes, I run with tests.
>
> You can also build in an offline mode (e.g. 'mvn -o clean install -DskipTests'). This avoids searching of maven repos, all together. So, you do need one full online build, before this will work. Due to the current development work going on in OpenWebBeans, OpenEJB, Aries, and Geronimo (I think these are the most frequently changing projects, ATM), you run the risk of getting out-of-date between the projects.
Ah, yes very good tip.
And the note on the risk would have to be included if the tip were given.
>
> FYI, we are running Continuous Integration builds. E.g. -- http://ci.apache.org/builders/geronimo-server-trunk/builds/106
>
> I encourage people to build from source. However, if you really want pre-built binaries of unreleased versions of Geronimo, assemblies from our CI builds are uploaded to the apache snapshot repository. So, it is possible to download SNAPSHOT builds from the SNAPSHOT repository. For example: https://repository.apache.org/content/repositories/snapshots/org/apache/geronimo/assemblies/geronimo-tomcat7-javaee6/3.0-SNAPSHOT/
Yes, I actually use these for testing use scenarios because they are always up
to date with trunk.
Building from source is for when testing code changes.
I think this should definitely be mentioned on the "Building Apache Geronimo"
page: "If you just want a build of the latest trunk, use can download from the
CI builds...."
>
>>
>>
>> I have been able to successfully build G3 from trunk several times now but with
>> differing build time results.
>>
>> The best build time I have had is 13 hours.
>> The worst build time I have had is 39 hours. (this is from my latest build)
>
> Ouch. My build times are nowhere near this long. Are you running with an empty local maven repository?
No, I have built G3.0 from trunk about a dozen times since the last time I
emptied my local maven repository. Believe it or not, the 13 hours build time
was starting from an empty local maven repository. So I was very surprised my
latest build finished this morning after 39 hours... the worst yet.
>
>>
>> I am using a very basic build procedure.
>> 1. checkout G3 trunk
>> 2. JAVA_HOME="/path/to/jdk/1.6.0_22"
>> 3. download and install a fresh maven 2.2.1
>> 4. MAVEN_OPTS="-Xmx968m -XX:MaxPermSize=500m -XX:ReservedCodeCacheSize=64m"
>
> My settings are similar. I don't specify '-XX:ReservedCodeCacheSize=64m'.
>
> I run with the following. I know there are others running with larger max heaps. I haven't :
>
> MAVEN_OPTS="-Xmx1024m -XX:MaxPermSize=512m -XX:+HeapDumpOnOutOfMemoryError"
The server I am build on has 1024MB of memory total, and has a dual dual-core
Intel(R) XEON(TM) CPU 2.00GHz with 512KB cache.
I have tried many JVM configurations, and the one like mine and yours is the
best one I have found. For me, a JVM configuration with less than 400m for
MaxPermSize always ended with an OutOfMemory error on PermGen space.
The Geronimo dev wiki suggests 200m for MaxPermSize, which never worked for me
for trunk. I always assumed it was because of all the snapshot downloading the
build process has to do. Even after the 2nd or 3rd build, 200m was never enough.
>
>> 5. mvn clean install
>> 6. 13 to 39 hours later == BUILD SUCCESS
>>
>>
>> From observing the build process, it would seem the most used (seemingly paused)
>> time is right before the build process moves on to the next plugin or assembly.
>>
>> This "seemingly paused time" after the assembly I assume is the packaging
>> process, because the resulting output is a huge collection.
>>
>> [INFO] Geronimo Assemblies ............................... SUCCESS [3.995s]
>> [INFO] Geronimo Assemblies :: Minimal + Jetty8 ........... SUCCESS [8:15.210s]
>> [INFO] Geronimo Assemblies :: Java EE 6 Web Profile + Jetty8 SUCCESS [1:57:17.311s]
>> [INFO] Geronimo Assemblies :: Java EE 6 + Jetty8 ......... SUCCESS [1:02:47.374s]
>> [INFO] Geronimo Assemblies :: Minimal + Tomcat7 .......... SUCCESS [8:08.838s]
>> [INFO] Geronimo Assemblies :: Java EE 6 Web Profile + Tomcat7 SUCCESS
>> [1:59:16.619s]
>> [INFO] Geronimo Assemblies :: Java EE 6 + Tomcat7 ........ SUCCESS [1:08:13.854s]
>>
>> That is ~1.5 hours for the "Java EE 6 Web Profile + Jetty8" and "Java EE 6 Web
>> Profile + Tomcat7" assemblies.
>
> Here are my build times. This is running without tests. Which would affect the overall build time. Assembly times would be unaffected -- we don't run any tests when building assemblies.
>
> [INFO] Geronimo Assemblies ............................... SUCCESS [0.163s]
> [INFO] Geronimo Assemblies :: Minimal + Jetty8 ........... SUCCESS [42.253s]
> [INFO] Geronimo Assemblies :: Java EE 6 Web Profile + Jetty8 SUCCESS [1:04.295s]
> [INFO] Geronimo Assemblies :: Java EE 6 + Jetty8 ......... SUCCESS [1:33.097s]
> [INFO] Geronimo Assemblies :: Minimal + Tomcat7 .......... SUCCESS [41.587s]
> [INFO] Geronimo Assemblies :: Java EE 6 Web Profile + Tomcat7 SUCCESS [1:14.409s]
> [INFO] Geronimo Assemblies :: Java EE 6 + Tomcat7 ........ SUCCESS [1:46.333s]
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD SUCCESS
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 28:15.199s
> [INFO] Finished at: Wed Jun 22 12:38:10 EDT 2011
> [INFO] Final Memory: 633M/1011M
> [INFO] ------------------------------------------------------------------------
Yours is about 1/3 faster than mine. But you might have a faster processor too.
Obviously, this part of the build is not the time consumer for me. It is nice to
know this part of the build is supposed to take several hours - that helps me
narrow down the issues.
>
>
>>
>>
>> For the plugins, I would assume the same, except that I notice that, of course,
>> the latest snapshot dependencies are being downloaded, and the poms in the maven
>> SNAPSHOT repositories are continually being accessed.
>>
>> I realize that because trunk (G3) largely depends on 3rd-party artifact
>> SNAPSHOTS that these repositories are checked during every build, and new
>> SNAPSHOT libraries are always being downloaded (as is the nature of snapshot
>> releases).
>
> Correct. A local maven proxy (e.g. Nexus) can reduce the overhead.
So it is worth noting as it already is now.
>
>>
>> As it is not a simple process for a user to setup a maven repo proxy, and could
>> be a deterrent to someone getting started if it were necessary to install a
>> proxy, I am looking at other methods and tips that might increase the speed of
>> building G3.
>
> I've tried running with a local maven proxy. However, I've found it to be too much trouble to maintain/configure.
Agreed. At least it is too much trouble if you are not continuously building the
entire trunk every day on the larger scale. So too much to ask a G3 beginner to do.
>
>>
>> Is this feasible? Or would we just say, that because of the nature of SNAPSHOT
>> builds and their dependencies on 3rd-party SNAPSHOT artifacts, there is no real
>> means to improving build speed unless a proxy is utilized?
>> If the later is true, I would like to add this note in the wiki's build
>> documentation. And also warn those who choose to build without a proxy may
>> experience a long build time.
>
> While I'm thinking about it -- what is your network environment? The focus on proxies imply that your slow build times are predominantly network issue. Are you certain that is the case?
We have about ~14Mb/s speed to the Internet. Our backplane is Gigabit Ethernet.
We are connected to a major Internet backbone provider.
I have been wondering if the problem is responsiveness of the maven repo sites.
I have been seeing on occasion a refusal to download an artifact from the site,
where as I was able to download it within a browser from the same URL.
So I wonder if the repo sites are either metering the usage on a per user or
session basis.
>
> --kevan
Thanks for the excellent tips!
I'll try some things out, and look at how to reflect the tips in the wiki
without degrading any affirmation of Best Practices (i.e. running the test cases
is good).
-RG
Re: Speeding up G3.0 build time
Posted by Kevan Miller <ke...@gmail.com>.
On Jun 22, 2011, at 12:09 PM, Russell E Glaue wrote:
> I am wanting to update the G3 dev wiki to help first-time builders get started.
> How would you suggest a build of G3 could become faster?
>
> The only tip I am aware of for speeding up trunk (G3) builds is to install a
> maven repository proxy like nexus. This is eluded to in the wiki already.
> Are there any other tips?
You can build without tests. E.g.: 'mvn clean install -DskipTests=true'. If I'm simply running a build, I'll frequently turn off tests ('-DskipTests=true' I think '-DskipTests' is equivalent). If I'm making code changes, I run with tests.
You can also build in an offline mode (e.g. 'mvn -o clean install -DskipTests'). This avoids searching of maven repos, all together. So, you do need one full online build, before this will work. Due to the current development work going on in OpenWebBeans, OpenEJB, Aries, and Geronimo (I think these are the most frequently changing projects, ATM), you run the risk of getting out-of-date between the projects.
FYI, we are running Continuous Integration builds. E.g. -- http://ci.apache.org/builders/geronimo-server-trunk/builds/106
I encourage people to build from source. However, if you really want pre-built binaries of unreleased versions of Geronimo, assemblies from our CI builds are uploaded to the apache snapshot repository. So, it is possible to download SNAPSHOT builds from the SNAPSHOT repository. For example: https://repository.apache.org/content/repositories/snapshots/org/apache/geronimo/assemblies/geronimo-tomcat7-javaee6/3.0-SNAPSHOT/
>
>
> I have been able to successfully build G3 from trunk several times now but with
> differing build time results.
>
> The best build time I have had is 13 hours.
> The worst build time I have had is 39 hours. (this is from my latest build)
Ouch. My build times are nowhere near this long. Are you running with an empty local maven repository?
>
> I am using a very basic build procedure.
> 1. checkout G3 trunk
> 2. JAVA_HOME="/path/to/jdk/1.6.0_22"
> 3. download and install a fresh maven 2.2.1
> 4. MAVEN_OPTS="-Xmx968m -XX:MaxPermSize=500m -XX:ReservedCodeCacheSize=64m"
My settings are similar. I don't specify '-XX:ReservedCodeCacheSize=64m'.
I run with the following. I know there are others running with larger max heaps. I haven't :
MAVEN_OPTS="-Xmx1024m -XX:MaxPermSize=512m -XX:+HeapDumpOnOutOfMemoryError"
> 5. mvn clean install
> 6. 13 to 39 hours later == BUILD SUCCESS
>
>
> From observing the build process, it would seem the most used (seemingly paused)
> time is right before the build process moves on to the next plugin or assembly.
>
> This "seemingly paused time" after the assembly I assume is the packaging
> process, because the resulting output is a huge collection.
>
> [INFO] Geronimo Assemblies ............................... SUCCESS [3.995s]
> [INFO] Geronimo Assemblies :: Minimal + Jetty8 ........... SUCCESS [8:15.210s]
> [INFO] Geronimo Assemblies :: Java EE 6 Web Profile + Jetty8 SUCCESS [1:57:17.311s]
> [INFO] Geronimo Assemblies :: Java EE 6 + Jetty8 ......... SUCCESS [1:02:47.374s]
> [INFO] Geronimo Assemblies :: Minimal + Tomcat7 .......... SUCCESS [8:08.838s]
> [INFO] Geronimo Assemblies :: Java EE 6 Web Profile + Tomcat7 SUCCESS
> [1:59:16.619s]
> [INFO] Geronimo Assemblies :: Java EE 6 + Tomcat7 ........ SUCCESS [1:08:13.854s]
>
> That is ~1.5 hours for the "Java EE 6 Web Profile + Jetty8" and "Java EE 6 Web
> Profile + Tomcat7" assemblies.
Here are my build times. This is running without tests. Which would affect the overall build time. Assembly times would be unaffected -- we don't run any tests when building assemblies.
[INFO] Geronimo Assemblies ............................... SUCCESS [0.163s]
[INFO] Geronimo Assemblies :: Minimal + Jetty8 ........... SUCCESS [42.253s]
[INFO] Geronimo Assemblies :: Java EE 6 Web Profile + Jetty8 SUCCESS [1:04.295s]
[INFO] Geronimo Assemblies :: Java EE 6 + Jetty8 ......... SUCCESS [1:33.097s]
[INFO] Geronimo Assemblies :: Minimal + Tomcat7 .......... SUCCESS [41.587s]
[INFO] Geronimo Assemblies :: Java EE 6 Web Profile + Tomcat7 SUCCESS [1:14.409s]
[INFO] Geronimo Assemblies :: Java EE 6 + Tomcat7 ........ SUCCESS [1:46.333s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 28:15.199s
[INFO] Finished at: Wed Jun 22 12:38:10 EDT 2011
[INFO] Final Memory: 633M/1011M
[INFO] ------------------------------------------------------------------------
>
>
> For the plugins, I would assume the same, except that I notice that, of course,
> the latest snapshot dependencies are being downloaded, and the poms in the maven
> SNAPSHOT repositories are continually being accessed.
>
> I realize that because trunk (G3) largely depends on 3rd-party artifact
> SNAPSHOTS that these repositories are checked during every build, and new
> SNAPSHOT libraries are always being downloaded (as is the nature of snapshot
> releases).
Correct. A local maven proxy (e.g. Nexus) can reduce the overhead.
>
> As it is not a simple process for a user to setup a maven repo proxy, and could
> be a deterrent to someone getting started if it were necessary to install a
> proxy, I am looking at other methods and tips that might increase the speed of
> building G3.
I've tried running with a local maven proxy. However, I've found it to be too much trouble to maintain/configure.
>
> Is this feasible? Or would we just say, that because of the nature of SNAPSHOT
> builds and their dependencies on 3rd-party SNAPSHOT artifacts, there is no real
> means to improving build speed unless a proxy is utilized?
> If the later is true, I would like to add this note in the wiki's build
> documentation. And also warn those who choose to build without a proxy may
> experience a long build time.
While I'm thinking about it -- what is your network environment? The focus on proxies imply that your slow build times are predominantly network issue. Are you certain that is the case?
--kevan