ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maarten Coene <>
Subject Re: Ivy + hudson CI - problems downloading artifacts, please, help
Date Fri, 26 Feb 2010 23:50:55 GMT
ok, I've found a place in the Ivy code that could cause the resolve to hang.
I've fixed that particular problem in SVN trunk. Could you try again with the latest Ivy code
from trunk to see if the problem has been fixed?


----- Original Message ----
From: David Goblirsch <>
Sent: Fri, February 26, 2010 12:28:30 AM
Subject: Re: Ivy + hudson CI - problems downloading artifacts, please, help

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,
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 acquired", "reentrant lock acquired", "reentrant lock released", "lock released on"
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


View raw message