Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
Subject: Ivy: resolve latest.status (IVY-854)
From: Hans Lund <hl@multi-support.com>
To: dev@ant.apache.org
Organization: MultiSupport R&D
Date: Fri, 04 Jul 2008 13:22:35 +0200
Message-Id: <1215170555.14048.46.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8

I'm moving this from ivy-users:

...
=EF=BB=BFrunning:
> >
> > <ivy:resolve conf=3D"runtime" />
> > But: After a short while running on a CI (hudson) server, where the
ivy
> > repository also is placed, resolving stops working due to connection
> > problems in httpClient.
> > ---
> >
> > [ivy:resolve] 01-07-2008 13:16:24
> > org.apache.commons.httpclient.HttpMethodDirector executeWithRetry
> > [ivy:resolve] INFO: I/O exception (java.net.BindException) caught
when
........

> >
> > which in the end results in unresolved dependencies.

It looks like ivy:resolve is over aggressive towards the http reposiory.


Basically I think that Ivy url resolver should operate with the same
practice as a web crawler, that is limit the load on the http-server to
a configurable load (max concurrent connections).

Also, A reasonable error handler for the executeWithRetry, should be in
place, now tries 5 times in a row. The exception here (address in use)
on http always comes when the tcp stack on the server is exhausted, so
trying again right away, might not be the best error handler :-).
Improving error handling though, will have no effect if the ivy behavior
is not changed.=20
(This I think, should be considered httpClient features???) =20

Regarding latest.status resolving strategy:
As far as I can see the latest.status resolving fetches all ivy files
and checksum files, which for n revisions is 2(n-1) too many http calls
(and maybe also other calculations). Downloading checksum files for any
other revision than latest.status, should be an error handle if the
checksums don't match the ivy-file that resolves to latest.status.
This should also speed up the resolving a tiny bit :-)


Now someone with inside knowledge of ivy, pleace comment. Right now I
have no idea about the size of such changes, or even if this is the
right strategy (eq. an alternative for ivy repositories could be to have
an additional archive format, where all meta-data is stored in one file,
and let ivy:publish update the archive along with normal publishing
tasks)

Regards
Hans Lund   =20


  =20


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org