Mailing-List: contact dev-help@groovy.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@groovy.incubator.apache.org
Received-SPF: error (athena.apache.org: encountered temporary error during SPF
 processing of domain of blackdrag@gmx.org)
Message-ID: <5540A2B6.6030009@gmx.org>
Date: Wed, 29 Apr 2015 11:21:58 +0200
From: Jochen Theodorou <blackdrag@gmx.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: dev@groovy.incubator.apache.org
Subject: Re: Groovy Grape/Ivy thread safe?
References: <553D09D1.4010807@span.ch> <553FDC5F.20002@span.ch>
In-Reply-To: <553FDC5F.20002@span.ch>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Am 28.04.2015 21:15, schrieb Alain Stalder:
> Hi again,
>
> Looks like everybody is busy with stuff on a somewhat lower level of
> Maslov's Pyramid? ;)

looks like I forgot to answer...

> So, I will simply answer myself to my questions:
>
>  > It looks to me like Grape resp. ivy is not thread safe.
>  >
>  > Question 1: Is that a bug or just how things currently are? (If it's
> a bug, rather Grape bug or an ivy bug, resp. where would I best file it?)
>
> I consider that a bug, even though it seems to me that fixing it might
> possibly be not so simple...

not only grape and ivy, also the groovy compiler

> I created an account for the Groovy Apache JIRA, resp. seems like my
> user had been already transferred there (or maybe I created an account
> in the past and forgotten about it), with the intent to file a bug with
> Groovy, but apparently I don't have the rights to do so?
> If its possible without jumping through too many hoops, I would still be
> available to file the bug (how?), else this post will have to suffice... ;)

so you have been able to login, but not to file an issue for groovy? In 
that case, give me your username and I make an issue for INFRA

[...]
> Question 3 (new): Am I stuck?
>
> No, I am not, at least not with Grengine: http://grengine.ch
>
> I can simply override DefaultGroovyCompiler with a class that
> synchronizes around CompilationUnit.compile(), since Grengine is not
> using GroovyClassLoader, GroovyShell or GroovyScriptEngine, except a
> GroovyClassLoader during compilation. (Of course, in order to use Grape,
> a GroovyClassLoader has to be in the classpath at runtime (or a
> RootLoader, actually is there any real reason for that?), but that is
> also possible to do by configuring Grengine.)
>
> Or is there a workaround that works with Groovy itself, on the level of
> the compiler or GroovyClassLoader/GroovyShell/GroovyScriptEngine, except
> synchronizing each an every call that might compile anything?

The thing is you created a single point of entry and synchronize there. 
Any compilation that goes not through there will have the same trouble. 
You are aware of that I am sure, just mentioning it for the interested 
reader. There is a point like that in GroovyClassLoader (GCL) with 
parseClass. It too uses synchronization to avoid multiple parallel 
compilations. Of course with a similar limitation - compile with two GCL 
instances and you have the same potential problem again.

doing that on the level of Grape would be maybe better....even better 
would be probably to do that in Ivy itself... in which case we would 
probably have to make the fix ourselves as well I guess.

bye blackdrag

-- 
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/