Mailing-List: contact notifications-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ant.apache.org
Message-ID: <1720106958.1225810244311.JavaMail.jira@brutus>
Date: Tue, 4 Nov 2008 06:50:44 -0800 (PST)
From: "Martin Stenderup (JIRA)" <jira@apache.org>
To: notifications@ant.apache.org
Subject: [jira] Issue Comment Edited: (IVY-654) Share cache with locking
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/IVY-654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12644959#action_12644959 ] 

mast edited comment on IVY-654 at 11/4/08 6:50 AM:
---------------------------------------------------------------

I have a suspicion that there still might be an issue with concurrency.
I get several errors like this when building multiple projects simultaneously on Hudson:
[ivy:cachepath] 		[FAILED     ] external#dom4j#trunk;1.6.1!dom4j-1.6.1.jar: impossible to move part file to definitive one: c:\build\ivy\external\dom4j\trunk\jars\dom4j-1.6.1-1.6.1.jar.part -> c:\build\ivy\external\dom4j\trunk\jars\dom4j-1.6.1-1.6.1.jar (141ms)

I am using Ivy 2.0.0-RC2 from the developers mailing list and the ivysvn (2.0.0-beta4) resolver .

I will investigate it a bit further to see if I can provide you with some more information on the issue.

Update: I have confirmed the issue. The workaround  is to make "ivy.cache.dir" dependent on the environment variable "EXECUTOR_NUMBER" which is set by Hudson. Thereby having a cache directory per executor.

  
> Share cache with locking
> ------------------------
>
>                 Key: IVY-654
>                 URL: https://issues.apache.org/jira/browse/IVY-654
>             Project: Ivy
>          Issue Type: New Feature
>          Components: Core
>            Reporter: Xavier Hanin
>            Assignee: Xavier Hanin
>             Fix For: 2.0.0-beta-1
>
>
> Currently it isn't possible use the same cache from multiple processes. This is a problem in some situations, especially for build servers, which have to use one cache per process, defeating some of the purpose of the cache. Adding an option allowing to use cache locking to ensure the repository cache can be used by concurrent build would be a nice improvement.
> To avoid degrading performance of local builds where the cache is not shared, this should only be an option.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.