[
https://jira.codehaus.org/browse/MNG-5437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=320112#comment-320112
]
Martin Desruisseaux commented on MNG-5437:
------------------------------------------
The proposed patch may help in making Maven build more robust when running
builds in parallel, thanks a lot for proposing it. But I wonder if this is a
common cases? In the particular case of the JVM crash reported in the SIS
project, there is no parallel build, and I don't see which process could be
cobbling the JAR file at the time of the JVM crash... So it is quite possible
that the JVM crash has another cause. One think we could do first would be to
upgrade JDK7 on the Jenkins server (which is 18 months old), then see if the
crashes are still there.
> Do not load plugins from snapshot JARs
> --------------------------------------
>
> Key: MNG-5437
> URL: https://jira.codehaus.org/browse/MNG-5437
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Class Loading
> Affects Versions: 3.0.4
> Environment: Solaris 10, JDK 1.7.0
> Reporter: Jesse Glick
> Priority: Minor
>
> See [mailing list
> discussion|http://mail-archives.apache.org/mod_mbox/www-builds/201302.mbox/browser]
> for background. When a reactor build creates a plugin JAR and then loads
> classes from it, a JVM crash is a possibility:
> {code:none}
> [INFO] Installing
> /export/home/hudson/hudson-slave/workspace/sis-jdk7/sis-build-helper/target/sis-build-helper-0.3-jdk7-SNAPSHOT.jar
> to
> /export/home/hudson/hudson-slave/maven-repositories/0/org/apache/sis/sis-build-helper/0.3-jdk7-SNAPSHOT/sis-build-helper-0.3-jdk7-SNAPSHOT.jar
> ...moving on to another project in the reactor...
> [INFO] --- sis-build-helper:0.3-jdk7-SNAPSHOT:collect-jars (default) @
> sis-utility ---
> #
> # A fatal error has been detected by the Java Runtime Environment:
> {code}
> This could happen for example if two people were running the same build
> concurrently; if one Maven process is trying to load classes from the JAR at
> the same time as another is rebuilding that JAR, there will be a problem. On
> Windows, one of the processes will simply fail with an I/O error due to
> mandatory file locks. On Unix, the OS will not stop the clash in this way,
> but there will be a worse issue: {{libzip.so}} will be trying to load a ZIP
> entry based on a stale copy of the ZIP index, so it loads bogus data, and
> (being not very robustly written) crashes, taking the whole JVM with it.
> Since this class of problem is most likely to occur when loading classes from
> {{SNAPSHOT}} JARs in the local repository, I would suggest Maven simply not
> do this. Instead, use {{File.createTempFile}} to make a new {{/tmp/*.jar}};
> use {{deleteOnExit}} to clean it up at process end (or if possible delete it
> sooner, e.g. upon conclusion of the reactor build, or at any time when it can
> be determined that mojo execution from this JAR must have ceased); copy the
> snapshot JAR from the local repo to this temp location; and load from there.
> This means that problems will be limited to the much less likely event that
> someone is rebuilding the JAR during the very short period during which the
> file copy happens. And on Unix, the result might be a corrupted JAR file (and
> thus class loading errors which fail the build somehow), but not a mysterious
> JVM crash.
> If this proposal sounds good, let me know and I can try to write a patch.
> (GitHub pull request would be easiest; I am an Apache committer.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
