mvn clean install results in the following which stalls until I kill the process. This only happens as a part of a much larger build on a bamboo server. When I build locally the build doesn't stall.
[INFO] --- gwt-maven-plugin:2.4.0:compile (default) # alerts ---
[WARNING] Don't declare gwt-dev as a project dependency. This may introduce complex dependency conflicts
[INFO] Compiling module com....alerts.Alerter
What can I do to gain better insight into the hang?
What are the likely causes of the hang?
This is likely a problem with memory. If you are bounded by x86 limits (as I am in this case) then you can use gwt.localWorker to reduce memory footprint. Fewer workers translates to less parallel needs and a longer build. Increasing memory may prevent the problem. Increasing the logLevel may expose the nature of the stall.
The following got me past my stall.
<gwt.compiler.localWorkers>1</gwt.compiler.localWorkers>
<gwt.logLevel>TRACE</gwt.logLevel>
<gwt.extraJvmArgs>-Xmx1024m -Djava.io.tmpdir=target</gwt.extraJvmArgs>
Suggestions For Improving Rep Ability
- Compare environment settings between build server and local for better ability to rep. JAVA_OPTS and MAVEN_OPTS may import
- Ensure you use identical build commands in both contexts
- try running with -pl :module-artifact-name on build server to reduce time to failure
- mvn -X will provide some additional
Related
I have a simple Gradle project that has org.gradle.caching=true set in gradle.properties in order to enable the local build cache.
When I run the build directly (./gradlew clean build) I can see that the local build cache is being used: https://scans.gradle.com/s/ykywrv3lzik3s/performance/build-cache
However, when I run the build with Coverity (bin/cov-build --dir cov-int ./gradlew clean build) I see the build cache is disabled for the same build: https://scans.gradle.com/s/j2pvoyhgzvvxk/performance/build-cache
How is Coverity causing the build cache to be disabled, and is there a way to run a build with Coverity and the Gradle Build Cache?
You can't use the build cache with Coverity, or at least you don't want to.
The Gradle Build Cache causes compilation to be skipped:
The Gradle build cache is a cache mechanism that aims to save time by reusing outputs produced by other builds. The build cache works by storing (locally or remotely) build outputs and allowing builds to fetch these outputs from the cache when it is determined that inputs have not changed, avoiding the expensive work of regenerating them.
Were that mechanism to be used with Coverity, it would prevent cov-build from seeing the compilation steps, and hence it would be unable to perform its own compilation of the source code, which is a necessary prerequisite to performing its static analysis.
I don't know precisely how Coverity is disabling the cache (or if that is even intentional on Coverity's part), but if it didn't do so, then you would have to yourself, as described in the Synopsys article Cov-build using gradle shows "No files were emitted" error message, the key step of which is:
Use "clean" and "cleanBuildCache" task to remove all saved cache data which prevent full compilation.
before running cov-build.
System info
Software info
OS:
Java: OpenJDK 12.0.2
Gradle: 5.6.2
The issue
Building Gradle multi-project with parallel builds enabled consumes almost all the CPU time. PC is not interactable during the build process
Steps to reproduce
1. git clone --recursive https://github.com/vividus-framework/vividus.git
2. cd vividus
3. ./gradlew build
In your gradle.properties file (or GRADLE_OPTS environment variable), try setting org.gradle.priority=low. On my machine it has a noticeable effect with parallel enabled, but I've also heard from some of my co-workers with older machines that this setting didn't help them too much.
You can also experiment with setting org.gradle.workers.max. It defaults to the number of CPU processors. Maybe set it to the number of logical processors minus one.
If it still stops you from interacting with your computer during the build, you should probably just disable parallel execution and let Gradle work on a single processor.
Every build takes an extra 3-4 seconds, pausing immediately after the log output prints the following.
[LIFECYCLE]
[org.jetbrains.kotlin.gradle.plugin.KotlinGradleBuildServices] Forcing
System.gc()
Why is it "forcing" this? How do I avoid this and speed up my build?
I've looked into this, and this is a consequence of having Gradle's debug-level logging enabled (eg. gradle --debug assemble).
Run Gradle without debug logging enabled (eg. gradle --info assemble) and this should not occur anymore.
References: libraries/tools/kotlin-gradle-plugin/src/main/kotlin/org/jetbrains/kotlin/gradle/plugin/KotlinGradleBuildServices.kt
Kotlin Gradle plugins calls System.gc before and after a build only when debug logging is enabled (Gradle is run with -d or --debug command line argument).
Users do not normally run Gradle with debug logging enabled because it is extremely noisy and slow, so forcing a GC is a relatively minor issue.
Historically this behaviour was added to test against memory leaks when Gradle daemon is enabled. The idea was to log a difference of used memory before and after a build, run a few builds consequently in a test, and assert that the difference is not exceeding the threshold.
I think calling System.gc should be avoided unless the test KotlinGradleIT#testKotlinOnlyDaemonMemory is running, so I've created an issue at Kotlin bugtracker https://youtrack.jetbrains.com/issue/KT-17960
I use the Alfresco SDK with the following command:
mvn install -Ddependency.surf.version=6.3 -Prun
All is fine, except when it gets stuck at this step of Building Alfresco Share WAR Aggregator:
[INFO] --- maven-war-plugin:2.6:war (default-war) # share ---
[INFO] Packaging webapp
[INFO] Assembling webapp [share] in [/home/nico/aegif/projects/60_townpage/townpage-filing/townpage-filing/share/target/share-1.0-SNAPSHOT]
[info] Copying manifest...
[INFO] Processing war project
[INFO] Processing overlay [ id org.alfresco:share]
In such cases I just perform a clean and the problem is solved, but that takes time.
Is there anything I can do to avoid it getting stuck?
alfresco.version is 5.1.g
Ubuntu 2016.10 LTS
Given the parameters you are using, I assume you are on Alfresco SDK 2.2, and trying to use a more recent version of alfresco (5.1.f or newer) on a All In One project.
Using Alfresco SDK AIO projects always adds some overhead during restarts because the SDK is actually building your modules, fetching the wars, fetching additional modules referenced and applies the modules to the wars (as in unzipping the war and unzipping the amps on the same folder before re-packaging the wars), then it starts up an embedded tomcat with some special config from the runner project with the new wars! A complicated approach, if you ask me, and it is definitely expected to take a considerable amount of time and performance (especially on Disk IO), especially when you clean before you rebuild...
Back to your question, the step you are hanging on if when the SDK is trying to unzip the OOTB share war prior to applying amps to it, and there is a lot of reasons why things could go south there! And unless you rovide some more detailed steps (as in adding -X or -e to your mvn command) I doubt any one would be able to catch precisely what is going wrong !
Be careful with running your project without cleaning, as you might end up with some risidual files that give you a different behaviour from the one to be expected from final artifacts... I can imagine at least a couple of these scenarios !
Alternatively, may I suggest that you switch from AIO approach to seperate projects for Repo and Share ? You can install multiple tomcats on your machine: Let's say a tomcat for repo on port 8080 and a tomcat for share on 8081, then you can develop on one tier while having a tomcat service provide the other one (Stop the share tomcat service, and start up a share amp from the SDK pointing to the local Alfresco Repo service on the the other locally installed tomcat) that way you can rapidly always clean and run with this command for running share:
mvn clean install -PampToWar -Dmaven.tomcat.port=8081 -Ddependency.surf.version=6.3
Scenario
While using the Maven Ant Task artifact:deploy, I'm encountering the error java.lang.OutOfMemoryError: Java heap space.
I'm only getting the error if the size of the file being deployed is greater than 25 MB. My artifacts are not greater than 50 MB in size.
What could the reason be? And, what can I do to fix it?
Code snippet
<artifact:deploy file="#{app.name}.jar">
<pom file="#{pom.file}"/>
<remoteRepository url="http://xxx.com:xxx/xxx-webapp/content/repositories/xxx-releases/">
<authentication username="xxx" password="xxx" />
</remoteRepository>
</artifact:deploy>
Existing solutions
Most online results indicate that it's something to do with the JVM default heap size and that it can be fixed by setting the appropriate environmental variables.
However, I would want the Ant scripts to run on any computer and not to depend on the environmental variables.
Is there a way to configure these settings in the Ant scripts or the
POM file?
EDIT
The install-provider task (http://maven.apache.org/ant-tasks/examples/install-deploy.html) seems to work for some people. I keep getting download errors when I use it.
Answer
It turns out that I'm not getting the Java heap error when I run my Maven Ant task on a different machine (which probably has more memory allocated to the JVM heap). Hence, I haven't attempted the solution mentioned by #Attila, though it seems to be going in the right direction.
Once ant is running, you cannot change the heap size of the JVM runing ant. So your only option is to run the task that comsumes a large amount of memory in a separate JVM, specifying enough heap space. Note this relies on the task allowing you to fork a new JVM to execute the task
Update: I could not find a way to specify to fork the maven (deploy) task, but this page specifies how you can define a macro to run maven using the java task (note that this relies on maven beeing installed and properly configured on the machine) (see the "Using the Java Task" section)
please try to increase VM memory, eg.: -Xmx512m
if you are using ANT, you can add it to the ANT_OPTS environment variable: ANT_OPTS="-Xmx512m"