Concurrency issues with multiple XjcGenerate task executions?

[chrisdennis]

I hesitate to file this as an issue since I have little solid evidence pointing to what the actual bug is here. In my multi-module project with three separate XjcGenerate executions in three different modules I see occasional failures (1 in every 20 or more builds). When constraining the XjcGenerate tasks to run one at a time these failures seem to disappear (based on my current testing).

Environment (reproduces across both Windows and MacOS):

• gradle-xjc-plugin: 2.0.0
• Gradle: 7.0.0
• Java: 1.8.0_292

Examples of the exceptions I'm seeing:

java.lang.NullPointerException
        at com.sun.xml.xsom.impl.parser.ParserContext.<init>(ParserContext.java:78)
        at com.sun.xml.xsom.parser.XSOMParser.<init>(XSOMParser.java:83)
        at com.sun.tools.xjc.ModelLoader.createXSOMParser(ModelLoader.java:378)
        at com.sun.tools.xjc.ModelLoader.createXSOMSpeculative(ModelLoader.java:451)
        at com.sun.tools.xjc.ModelLoader.loadXMLSchema(ModelLoader.java:310)
        at com.sun.tools.xjc.ModelLoader.load(ModelLoader.java:121)
        at com.sun.tools.xjc.ModelLoader.load(ModelLoader.java:76)
        at org.unbrokendome.gradle.plugins.xjc.work.common.AbstractXjcGeneratorWorkAction.doExecute(AbstractXjcGeneratorWorkAction.kt:49)
        at org.unbrokendome.gradle.plugins.xjc.work.common.AbstractXjcGeneratorWorkAction.execute(AbstractXjcGeneratorWorkAction.kt:39)

org.xml.sax.SAXParseExceptionpublicId: http://www.terracotta.org/config; systemId: jar:file:/Users/cdennis/.gradle/caches/modules-2/files-2.1/org.terracotta/tcconfig-schema/10.7.1/d4d92ada2276b9add5f5389c248f9ee0019ea6e/tcconfig-schema-10.7.1.jar!/terracotta.xsd; lineNumber: 331; columnNumber: 47; undefined simple type 'xs:positiveInteger'
        at com.sun.xml.xsom.impl.parser.ParserContext$1.reportError(ParserContext.java:150)
        at com.sun.xml.xsom.impl.parser.NGCCRuntimeEx.reportError(NGCCRuntimeEx.java:149)
        at com.sun.xml.xsom.impl.parser.DelayedRef.resolve(DelayedRef.java:80)
        at com.sun.xml.xsom.impl.parser.DelayedRef.run(DelayedRef.java:55)
        at com.sun.xml.xsom.impl.parser.ParserContext.getResult(ParserContext.java:105)
        at com.sun.xml.xsom.parser.XSOMParser.getResult(XSOMParser.java:184)
        at com.sun.tools.xjc.ModelLoader.createXSOMSpeculative(ModelLoader.java:457)
        at com.sun.tools.xjc.ModelLoader.loadXMLSchema(ModelLoader.java:310)
        at com.sun.tools.xjc.ModelLoader.load(ModelLoader.java:121)
        at com.sun.tools.xjc.ModelLoader.load(ModelLoader.java:76)
        at org.unbrokendome.gradle.plugins.xjc.work.common.AbstractXjcGeneratorWorkAction.doExecute(AbstractXjcGeneratorWorkAction.kt:49)
        at org.unbrokendome.gradle.plugins.xjc.work.common.AbstractXjcGeneratorWorkAction.execute(AbstractXjcGeneratorWorkAction.kt:39)

java.util.MissingResourceException: Can't find bundle for base name com.sun.tools.xjc.reader.xmlschema.MessageBundle, locale en_US
        at com.sun.tools.xjc.reader.xmlschema.Messages.format(Messages.java:23)
        at com.sun.tools.xjc.reader.xmlschema.ClassSelector.addSchemaFragmentJavadoc(ClassSelector.java:385)
        at com.sun.tools.xjc.reader.xmlschema.ClassSelector.access$300(ClassSelector.java:63)
        at com.sun.tools.xjc.reader.xmlschema.ClassSelector$Binding.build(ClassSelector.java:157)
        at com.sun.tools.xjc.reader.xmlschema.ClassSelector._bindToClass(ClassSelector.java:320)
        at com.sun.tools.xjc.reader.xmlschema.ClassSelector.bindToType(ClassSelector.java:250)
        at com.sun.tools.xjc.reader.xmlschema.DefaultClassBinder.elementDecl(DefaultClassBinder.java:258)
        at com.sun.tools.xjc.reader.xmlschema.DefaultClassBinder.elementDecl(DefaultClassBinder.java:66)
        at com.sun.tools.xjc.reader.xmlschema.ClassBinderFilter.elementDecl(ClassBinderFilter.java:101)
        at com.sun.tools.xjc.reader.xmlschema.Abstractifier.elementDecl(Abstractifier.java:35)
        at com.sun.tools.xjc.reader.xmlschema.Abstractifier.elementDecl(Abstractifier.java:22)
        at com.sun.xml.xsom.impl.ElementDecl.apply(ElementDecl.java:240)
        at com.sun.tools.xjc.reader.xmlschema.ClassSelector._bindToClass(ClassSelector.java:290)
        at com.sun.tools.xjc.reader.xmlschema.ClassSelector.bindToType(ClassSelector.java:232)
        at com.sun.tools.xjc.reader.xmlschema.BGMBuilder.populate(BGMBuilder.java:322)
        at com.sun.tools.xjc.reader.xmlschema.BGMBuilder.buildContents(BGMBuilder.java:281)
        at com.sun.tools.xjc.reader.xmlschema.BGMBuilder._build(BGMBuilder.java:146)
        at com.sun.tools.xjc.reader.xmlschema.BGMBuilder.build(BGMBuilder.java:89)
        at com.sun.tools.xjc.ModelLoader.annotateXMLSchema(ModelLoader.java:366)
        at com.sun.tools.xjc.ModelLoader.load(ModelLoader.java:121)
        at com.sun.tools.xjc.ModelLoader.load(ModelLoader.java:76)
        at org.unbrokendome.gradle.plugins.xjc.work.common.AbstractXjcGeneratorWorkAction.doExecute(AbstractXjcGeneratorWorkAction.kt:49)
        at org.unbrokendome.gradle.plugins.xjc.work.common.AbstractXjcGeneratorWorkAction.execute(AbstractXjcGeneratorWorkAction.kt:39)
        ... 29 more
Caused by: java.io.IOException: Stream closed
        ... 52 more

[dlmiles]

Can you confirm there is only a single xjcGenerate execution per module and each module has its own build output directory to itself ?

It certainly looks like there isn't support for multiple xjcGenerate tasks per module. One aspect is the task calling cleanOutputDirs() early in generate(). https://github.com/unbroken-dome/gradle-xjc-plugin/blob/master/src/main/kotlin/org/unbrokendome/gradle/plugins/xjc/XjcGenerate.kt#L181

However I don't see that being the cause of your exceptions. I too have seen such random errors that disappear by running the tool again.

UPDATED: The support for multiple xjcGenerate tasks is in the use of multiple sourceSets by different names, like src/main/schema and src/alt/schema and src/another/schema the clean I talk of above only cleans a single sourceSet label at a time, like 'main' or 'alt' or 'another' this is the mechanism for concurrency in a single project AFAIKS.

[dlmiles]

@chrisdennis Can you confirm if you are using Windows ? are you using catalogs ? or classpath: or maven: references ?

I have not experienced any concurrency issues since doing the work for PR #47 and using the plugin over the past weeks (but I did not try to specifically address anything related to 'concurrency' in the PR, I did however provide a fix/workaround for Windows platform JAR locking from open file handle with long running Gradle process when catalogs/xml-resolver was being used).

Looking at your stack trace again, seeing references to #resolve() and seeing 'jar:file' and 'Stream closed' errors, I think the commits related to my Issue #48 have also addressed this bug report.

[chrisdennis]

Sorry... should have got back on this when I saw the earlier comment. I saw this reproducing on both Windows and MacOS, and yes, the build is using catalogs with classpath: references.

[dlmiles]

Thanks for your comment, no problem on delay.
To give you my thoughts in a response: I continue to maintain the view in my previous comment.

Description of the sequence of events that may cause it on MacOS/Linux:

• Gradle daemon starts
• target: clean (optional step)
• target: build
  • this builds a JAXB producer project (optional step if you don't need this project for the next step below)
  • this then builds a JAXB consumer project (using a catalog/classpath:)
  • JVM downloads / opens JAR file and maintains a JarFile cache entry for it (even after the build has completed, this is a JVM feature, not a Gradle/plugin bug)
  • build completes successfully
• At this time the Gradle daemon is still running and still has an open file handle and JAR Cache to the classpath: JAR
• target: clean (on windows this would fail, see my Integration Test to expose this, on MacOS/Linux I expect it to succeed an the file removed)
• target: build
  • this build a JAXB producer project successfully
  • this then builds a JAXB consumer project (using a catalog/classpath:)
  • JVM this time, has a cache JAR hit for the jar:file: entry and tries to use the cached file-handle, but when it goes to seek/read/access data in the file, it gets an error, which results in "Stream closed". What it should have done here was not use that cached file-handle and reopen the file from the path requested for a new file handle. Because the 'clean' removed it.

This OpenJDK bug report provided much information to me to help confirm it was relevant to the situation fixed by my commits. https://bugs.openjdk.org/browse/JDK-8246714 FWIW: I am not saying the cache poisoning described in the bug is being trigger by Gradle, it is just good background to underestand something not so obvious happening inside the JVM process. The bug here is the inconsistent state of the internal JarFile cache and the real-world disk data, due to Gradle being a build system and due to repeated clean, build, clean, build and Gradle long running daemon driving those targets in a background process.

This should be preventable with a workaround, by ensuring you shutdown the gradle daemon between builds, then you should not be able to observe any problem, as this effectively invalidate that internal cache.

HTH