I was not aware of any problems with the artifact-lock strategy. Could you provide more details, like for instance the ant output when setting the property "ivy.log.locking" to "true"
Maarten ----- Original Message ---- From: David Goblirsch <[email protected]> To: [email protected] Sent: Thu, February 25, 2010 7:15:26 PM Subject: Re: Ivy + hudson CI - problems downloading artifacts, please, help Maarten Coene wrote: > Could you confirm that your Ivy cache isn't accessed concurrently? > And if your Ivy cache is accessed by more than 1 Ivy process at a time, could > you check you did enable the artifact locking in your settings.xml? > Cfr. > http://ant.apache.org/ivy/history/latest-milestone/settings/lock-strategies.html > > > Maarten > > My experience with this is this. We resolve "compile" dependencies in one ant target, and then resolve "test" dependencies in another ant target. If the artifact-lock is "turned on" in the settings file, then the resolving of the "test" conf deadlocks and the ant build process just hangs. > ----- Original Message ---- > From: "[email protected]" <[email protected]> > To: [email protected]; Eugene Sajine <[email protected]> > Sent: Wed, February 24, 2010 5:37:48 PM > Subject: Ivy + hudson CI - problems downloading artifacts, please, help > > Hi, > > I'm not subscribed to the list, so, please, make sure you have my address in > CC for replies. > > We are having more than 150 projects in hudson CI with dependencies tracked > by Ivy (2.1.0). > > Lately we are having more and more problems with it because ivy cannot > copy/download artifacts correctly. > > There are two main errors we are getting: > 1. size of source file differs from the size of dest file > 2. impossible to move part file to definitive one > > In mailing list i found this answer from Xavier Hanin: > When Ivy downloads ivy files from a repository, it first download them to a > temporary file (used to be in temp directory until 2.0 beta 1, where the ivy > file is downloaded to the cache). Then it moves the temporary file to the > final location in the cache, and this is what seems to be failing for your > user. Cleaning the cache should fix the problem, if it happens frequently > you should try to investigate the issue. Maybe it is due to the use of the > same cache by multiple processes concurrently. This use case is supported > only with 2.0 beta 1, with the repository cache locking to avoid such > concurrency issues. > > As i mentioned above our version is 2.1.0, but we still have this issue > > I also saw the same problem reported before, but there was no answer > http://www.mail-archive.com/[email protected]/msg03152.html > > Thanks, > Eugene > > > > > >
