[jira] [Commented] (GROOVY-7407) Compiliation not thread safe if Grape / Ivy is used in Groovy scripts

["Jex Jexler (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/GROOVY-7407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14522782#comment-14522782 ] 

Jex Jexler commented on GROOVY-7407:
------------------------------------

I noticed that compilation can also fail if *compilation* is synchronized across GroovyClassLoader (GCL) instances, but *running* scripts is not.

For example, a script had the following imports:
{code}
    @Grab('org.apache.httpcomponents:httpclient:4.4.1')
    import org.apache.http.client.methods.HttpGet
    import org.apache.http.params.HttpConnectionParams
    import org.apache.http.impl.client.BasicResponseHandler
    import org.apache.http.impl.client.DefaultHttpClient
    import org.apache.http.util.EntityUtils
{code}
and used these classes in the script. As I understand it, further needed classes from httpclient are only loaded when instances of the above classes are created, i.e. at runtime of the script, which can apparently disturb compilation.

In any case, compilations (gcl.parse()) done while other scripts - that used different GCL instances to compile+load, but with parse(...) synchronized across all these instances and using the same httpclient classes via Grape imports - were started in separate threads (script.run()), would sometimes fail with:
{code}
    java.lang.NoClassDefFoundError: org/apache/http/HttpRequest
{code}
caused by:
{code}
    java.lang.ClassNotFoundException: org.apache.http.HttpRequest
{code}
(As a last-resort workaround for my specific use case, I allowed to define a number of retries for retrying compilation, which together with synchronizing compilation made things reliably operable in my use case.)

A stack trace for this (but no unit test, because I don't have one) is added next, "x-stacktrace-compile-while-other-scripts-running.txt".

> Compiliation 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)