ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Goblirsch <>
Subject Re: Ivy + hudson CI - problems downloading artifacts, please, help
Date Thu, 25 Feb 2010 23:28:30 GMT
Maarten Coene wrote:
> 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
If I put this line

<caches lockStrategy="artifact-lock"/>

into my Ivy settings file, and then start with a clean slate, i.e,
having completely cleared the local cache under .ivy2,
and then run ant 1.7.1 with -Divy.log.locking=true as you suggested, I 
see that
ant ends up in an "infinite" loop printing out log messages that say

Thread[main,5,main]   [large integer]  file creation failed  [filename]

where [filename] looks like


where [organisation] and [module] above are just placeholds for the 
actual names;
they are for one of my company's private library jars.

We are on a secure network behind a firewall, so all repositories are on 
our file system, and
our internal jars do not have version numbers attached. The
resolve is done with resolveMode="dynamic" in two different ant steps,
first for conf="compile" and then conf="test", where conf "test" extends 
conf "compile"
indirectly via another conf called "runtime". That is, "test" extends 
"runtime" extends "compile". The infinite
loop occurs during the 2nd resolve, for conf="test". This is just a 
build, so "runtime" isn't explicitly resolved for.

There are several dependencies found before this one that work fine, 
i.e., I see many "acquiring lock",
"lock acquired", "reentrant lock acquired", "reentrant lock released", 
"lock released on" messages
before it gets to this one. This dependency is correctly resolved for 
conf="compile", i.e., it is not
a conf="test" only dependency.

If I kill ant with C-c and then ant again, this time the loop occurs 
during the first resolve.

If I remove the line

<caches lockStrategy="artifact-lock"/>

the build completes just fine.

I hope this is enough information. As I said, this build is for 
proprietary software,
so it would take me a while to duplicate the problem with a stripped 
down setup.


> ----- Original Message ----
> From: David Goblirsch <>
> To:
> 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.
>> 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: "" <>
>> To:; Eugene Sajine <>
>> 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
>> We are having more than 150 projects in hudson CI with dependencies tracked by Ivy
>> 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
>> Thanks,
>> Eugene

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message