[
https://issues.apache.org/jira/browse/GROOVY-8097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ion Alberdi updated GROOVY-8097:
--------------------------------
Description:
Ivy does not support concurrent access to its resolution cache
https://issues.apache.org/jira/browse/IVY-654
Grape relies on Ivy. For this reason, Grape cannot support concurrent access to
its resolution cache neither.
When using the @Grab annotation in jenkins groovyCommand or
systemGroovyCommand, the related code is vulnerable to race conditions, making
the grab fail. When the race conditions appears in a systemGroovyCommand, we
have no choice but to reboot jenkins as all consecutive calls to @Grab fail.
Among the two solutions we tried:
- protect the calls to grab with a lock similar to ivy's "artifact-lock-nio"
strategy. Works but slow
- set Ivy's lock on the repository cache, and setup Grab to use a different
cache resolution cache for each concurrent jobs. The following code permits to
fix a test we did to reproduce the race condition.
{code}
static IvySettings createIvySettings(String resolutionPath, boolean
dumpSettings) {
// Copy/Paste/Purged from GrapeIvy.groovy
IvySettings settings = new IvySettings()
settings.load(new File(GROOVY_HOME, "grapeConfig.xml"))
// set up the cache dirs
settings.defaultCache = new File(GRAPES_HOME)
settings.setVariable("ivy.default.configuration.m2compatible", "true")
settings.setDefaultResolutionCacheBasedir(resolutionPath)
return settings
}
static GrapeIvy ivyWithCustomResolutionPath(String resolutionPath) {
Class<?> grapeIvyClass = Class.forName("groovy.grape.GrapeIvy");
Object instance = grapeIvyClass.newInstance()
Field field = grapeIvyClass.getDeclaredField("ivyInstance");
field.setAccessible(true);
field.set(instance, Ivy.newInstance(createIvySettings(resolutionPath)));
return ((GrapeIvy)instance)
}
{code}
We'd like to propose to add an additional argument to Grab to be able to setup
Ivy's resolution cache directory.
Note that this solution seems to have been adopted by these users too
https://rbcommons.com/s/twitter/r/3436/
Would you agree on such a feature ?
was:
Ivy does not support concurrent access to its resolution cache
https://issues.apache.org/jira/browse/IVY-654
Grape relies on Ivy. For this reason, Grape cannot support concurrent access to
its resolution cache neither.
When using the @Grab annotation in jenkins groovyCommand or
systemGroovyCommand, the related code is vulnerable to race conditions, making
the grab fail. When the race conditions appears in a systemGroovyCommand, we
have no choice but to reboot jenkins as all consecutive calls to @Grab fail.
Among the two solutions we tried:
- protect the calls to grab with a lock similar to ivy's "artifact-lock-nio"
strategy. Works but slow
- set Ivy's lock on the repository cache, and setup Grab to use a different
cache resolution cache for each concurrent jobs. The following code permits to
fix a test we did to reproduce the race condition.
{code}
static IvySettings createIvySettings(String resolutionPath, boolean
dumpSettings) {
// Copy/Paste/Purged from GrapeIvy.groovy
IvySettings settings = new IvySettings()
settings.load(new File(GROOVY_HOME, "grapeConfig.xml"))
// set up the cache dirs
settings.defaultCache = new File(GRAPES_HOME)
settings.setVariable("ivy.default.configuration.m2compatible", "true")
settings.setDefaultResolutionCacheBasedir(resolutionPath)
if (dumpSettings) {
dump(settings)
}
return settings
}
static GrapeIvy ivyWithCustomResolutionPath(String resolutionPath, boolean
dumpSettings) {
Class<?> grapeIvyClass = Class.forName("groovy.grape.GrapeIvy");
Object instance = grapeIvyClass.newInstance()
Field field = grapeIvyClass.getDeclaredField("ivyInstance");
field.setAccessible(true);
field.set(instance, Ivy.newInstance(createIvySettings(resolutionPath,
dumpSettings)));
return ((GrapeIvy)instance)
}
{code}
We'd like to propose to add an additional argument to Grab to be able to setup
Ivy's resolution cache directory.
Note that this solution seems to have been adopted by these users too
https://rbcommons.com/s/twitter/r/3436/
Would you agree on such a feature ?
> Add an argument to set the resolution cache path in @Grab
> ---------------------------------------------------------
>
> Key: GROOVY-8097
> URL: https://issues.apache.org/jira/browse/GROOVY-8097
> Project: Groovy
> Issue Type: New Feature
> Components: Grape
> Affects Versions: 2.4.8
> Reporter: Ion Alberdi
> Priority: Minor
>
> Ivy does not support concurrent access to its resolution cache
> https://issues.apache.org/jira/browse/IVY-654
> Grape relies on Ivy. For this reason, Grape cannot support concurrent access
> to its resolution cache neither.
> When using the @Grab annotation in jenkins groovyCommand or
> systemGroovyCommand, the related code is vulnerable to race conditions,
> making the grab fail. When the race conditions appears in a
> systemGroovyCommand, we have no choice but to reboot jenkins as all
> consecutive calls to @Grab fail.
> Among the two solutions we tried:
> - protect the calls to grab with a lock similar to ivy's "artifact-lock-nio"
> strategy. Works but slow
> - set Ivy's lock on the repository cache, and setup Grab to use a different
> cache resolution cache for each concurrent jobs. The following code permits
> to fix a test we did to reproduce the race condition.
> {code}
> static IvySettings createIvySettings(String resolutionPath, boolean
> dumpSettings) {
> // Copy/Paste/Purged from GrapeIvy.groovy
> IvySettings settings = new IvySettings()
> settings.load(new File(GROOVY_HOME, "grapeConfig.xml"))
> // set up the cache dirs
> settings.defaultCache = new File(GRAPES_HOME)
> settings.setVariable("ivy.default.configuration.m2compatible", "true")
> settings.setDefaultResolutionCacheBasedir(resolutionPath)
> return settings
> }
> static GrapeIvy ivyWithCustomResolutionPath(String resolutionPath) {
> Class<?> grapeIvyClass = Class.forName("groovy.grape.GrapeIvy");
> Object instance = grapeIvyClass.newInstance()
> Field field = grapeIvyClass.getDeclaredField("ivyInstance");
> field.setAccessible(true);
> field.set(instance,
> Ivy.newInstance(createIvySettings(resolutionPath)));
> return ((GrapeIvy)instance)
> }
> {code}
> We'd like to propose to add an additional argument to Grab to be able to
> setup Ivy's resolution cache directory.
> Note that this solution seems to have been adopted by these users too
> https://rbcommons.com/s/twitter/r/3436/
> Would you agree on such a feature ?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
