We are using the url resolver to access a Subversion controlled Ivy repository via https. Both the build machine and the machine hosting the repository have been under excessive loads lately and I suspect this is the problem -- I would just like to avoid having our Cruise Control process fail and upsetting the rest of the team ;-)
Xavier Hanin wrote: > > On 4/10/07, jgunz <[EMAIL PROTECTED]> wrote: >> >> >> I'm having an issue where Ivy sporadically fails to resolve dependencies >> that >> actually DO exist in my internal Ivy repository. I believe the problem is >> caused by heavy processor or network load on my development machines >> because >> usually rerunning the build will succeed. Is there any configuration I >> could >> do to perhaps extend the timeout used or add a retry attempt to >> resolution? >> >> An example failure I got this morning is... >> >> [FAILED ] [ antlr | antlr | 2.7.6rc1 ]/antlr.jar[jar] : Socket is >> closed >> (46ms) >> [NOT FOUND ] [ antlr | antlr | 2.7.6rc1 ]/antlr.jar[jar] >> >> >> Antlr does exist, when I reran my build it succeeded. The "socket is >> closed" >> message is not always the same -- I've seen a variety of error messages >> in >> this spot. > > > Never seen that before. Which resolver are you using? > For the timeout or retry configuration, unfortunately there is no such > feature. You can add a JIRA issue for that. > > - Xavier > > Any help would be appreciated. >> -- >> View this message in context: >> http://www.nabble.com/Sporadic-resolution-errors-tf3553442.html#a9921261 >> Sent from the ivy-user mailing list archive at Nabble.com. >> >> > > > -- > Learn Ivy at ApacheCon: http://www.eu.apachecon.com/ > Manage your dependencies with Ivy! > http://incubator.apache.org/ivy/ > > -- View this message in context: http://www.nabble.com/Sporadic-resolution-errors-tf3553442.html#a9921796 Sent from the ivy-user mailing list archive at Nabble.com.
