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 <dgoblir...@interactivebrokers.com>
To: ivy-u...@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 <dgoblir...@interactivebrokers.com>
To: ivy-u...@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: "eugu...@gmail.com" <eugu...@gmail.com>
To: ivy-u...@ant.apache.org; Eugene Sajine <eugu...@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-u...@ant.apache.org/msg03152.html
Thanks,
Eugene
