This bit me today... updated to tip Ivy and seems to be resolved--
thanks Maarten!
-Matt
On Feb 26, 2010, at 5:50 PM, Maarten Coene wrote:
> 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?
>
> thanks,
> Maarten
>
>
>
>
> ----- Original Message ----
> From: David Goblirsch <dgoblirsch@interactivebrokers.com>
> To: ivy-user@ant.apache.org
> 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
>
> [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
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>
>
|