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
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
[myhomedir]/.ivy2/cache/[organisation]/[module]/metadatas/metadata-[sometimestamp].ivy.lck
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
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.
Thanks.
>
>
>
> ----- Original Message ----
> From: David Goblirsch
> To: ivy-user@ant.apache.org
> 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: "Euguess@gmail.com"
>> To: ivy-user@ant.apache.org; 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 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/ivy-user@ant.apache.org/msg03152.html
>>
>> Thanks,
>> Eugene
>>
>>
>>
>>
>>
>>
>>
>
>
>
>
>