[
https://issues.apache.org/jira/browse/GROOVY-7407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14522986#comment-14522986
]
Jex Jexler commented on GROOVY-7407:
------------------------------------
Problems can even arise if compilation is synchronized between e.g.
GroovyClassLoader instances if scripts with Grape imports are *run* while
compilations are in progress: A script might grab Apache httplclient and import
a few classes from there. When the script is run, in creates instances of these
classes, which depend on classes in Apache httpcore, which is then loaded with
the help of Grape/Ivy, but not synchronized with the same lock as compilation,
so things may fail again (failures experimentally observed).
I tried a last-resort workaround by retrying compilation after a failure a
couple of times, but at least once even that did not help and might even have
gotten Ivy into a broken state, see stacktrace:
{code}
java.lang.NoClassDefFoundError: Could not initialize class org.apache.ivy.Ivy
at
org.apache.ivy.util.url.AbstractURLHandler.getUserAgent(AbstractURLHandler.java:69)
at
org.apache.ivy.util.url.BasicURLHandler.openStream(BasicURLHandler.java:162)
at
org.apache.ivy.core.settings.XmlSettingsParser.doParse(XmlSettingsParser.java:157)
at
org.apache.ivy.core.settings.XmlSettingsParser.parse(XmlSettingsParser.java:150)
at org.apache.ivy.core.settings.IvySettings.load(IvySettings.java:417)
at org.apache.ivy.core.settings.IvySettings$load.call(Unknown Source)
at groovy.grape.GrapeIvy.<init>(GrapeIvy.groovy:96)
at sun.reflect.GeneratedConstructorAccessor19.newInstance(Unknown
Source)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
at java.lang.Class.newInstance(Class.java:374)
at groovy.grape.Grape.getInstance(Grape.java:117)
at groovy.grape.Grape.grab(Grape.java:155)
at
groovy.grape.GrabAnnotationTransformation.visit(GrabAnnotationTransformation.java:358)
at
org.codehaus.groovy.transform.ASTTransformationVisitor$3.call(ASTTransformationVisitor.java:319)
at
org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:928)
at
org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:590)
at
org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:566)
at
org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:543)
at
groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:297)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:267)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:253)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:194)
[...]
at java.lang.Thread.run(Thread.java:745)
{code}
> Compilation not thread safe if Grape / Ivy is used in Groovy scripts
> --------------------------------------------------------------------
>
> Key: GROOVY-7407
> URL: https://issues.apache.org/jira/browse/GROOVY-7407
> Project: Groovy
> Issue Type: Bug
> Components: Compiler, Grape
> Affects Versions: 2.4.3
> Environment: Essentially independent of the environment, as long as
> Groovy scripts use Grape; also this bug seems to be present since at least
> Groovy 1.7.5.
> Reporter: Jex Jexler
> Assignee: Paul King
> Priority: Minor
> Labels: Compile, Grape, Groovy, Ivy
> Attachments: GrapeAndGroovyShellConcurrencyTest.java,
> GroovyCompileConcurrencyTest.java,
> stacktrace-GrapeAndGroovyShellConcurrencyTest-1.txt,
> stacktrace-GrapeAndGroovyShellConcurrencyTest-2.txt,
> stacktrace-GroovyCompileConcurrencyTest-1.txt,
> stacktrace-GroovyCompileConcurrencyTest-2.txt
>
>
> If Groovy scripts that import the same libraries via Grape are compiled in
> separate threads, compilation may fail due to race conditions.
> This does not happen if several threads use the *same* instance of
> GroovyClassLoader (GCL), because parseClass() uses synchronization.
> But as soon as different GCLs are used in separate threads or if the compiler
> is used directly (CompilationUnit.compile()), the issue occurs and
> compilation can fail.
> Two Java unit tests have be attached, which reproduce the issue, although
> this cannot be guaranteed with 100% certainty, because there is a race
> condition.
> Two different stacktraces have been observed for each unit test (with origins
> in Grape and in Ivy), which have also been attached (plus in a different
> environment (Tomcat webapp CentOS) once a an exception down in Ivy had been
> observed that seemed to be related to unzipping a JAR file, but no precise
> record of that exists any more).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
