[
https://issues.apache.org/jira/browse/GROOVY-8097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15907777#comment-15907777
]
Jex Jexler commented on GROOVY-8097:
------------------------------------
Assuming that using different GrapeIvy instances in parallel would be
thread-safe (which I do not know if it is the case) and a solution as proposed
above is envisaged:
I wouldn't want to administrate Ivy resolution cache directories in Groovy
scripts on a grab-by-grab or script-by-script basis; I would want Groovy to
handle this, maybe optionally given a base directory where to create unique
resolution cache directories, but preferably - if compatible with Ivy -
subdirectories of the normally configured resolution cache directory.
I would prefer a system property
{{groovy.grape.perGrabResolutionCacheDir=true/false}}
plus maybe (not necessarily)
{{@GrabConfig(perGrabResolutionCacheDir=true)}}
=> Each grab uses its own GrapeIvy instance with a resolution cache directory
<configured-ivy-resolution-cache-dir>/<dir-with-random-name>
I would probably not want/need the following, unless Ivy has a problem with
others creating subdirectories in its resolution cache directory:
{{@GrabConfig(perGrabResolutionCacheDir=true,
resolutionCacheDirBase='/someDir')}}
So, far I have no clear opinion what the best overall approach would be... Are
fixes in Ivy completely impossible, is the project dead?
> 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
> Attachments: grab.groovy, grapeConfig.xml
>
>
> 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. When
> the race condition 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 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 ? We'd be glad to propose a PR.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
