ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Goblirsch <dgoblir...@interactivebrokers.com>
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

   
[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

<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.

Thanks.

>
>
>
> ----- Original Message ----
> From: David Goblirsch <dgoblirsch@interactivebrokers.com>
> 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" <Euguess@gmail.com>
>> To: ivy-user@ant.apache.org; Eugene Sajine <euguess@gmail.com>
>> 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
>>
>>
>>
>>      
>>
>>  
>>     
>
>
>       
>
>   


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