ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <stev...@iseran.com>
Subject Re: odd code in Get.java
Date Wed, 21 Mar 2001 23:40:26 GMT

----- Original Message -----
From: "Stefan Bodewig" <bodewig@apache.org>
To: <ant-dev@jakarta.apache.org>
Sent: Monday, March 19, 2001 23:36
Subject: Re: odd code in Get.java


> Steve Loughran <steve_l@iseran.com> wrote:
>
> > If you look at line 148 onwards, you see that the code makes a
> > number of attempts to connect to the server before bailing out,
> > eating any IO exceptions and retrying. Then there is some followon
> > code which recognises that the three attempts failed, and generates
> > a new exception (losing any IO exception information in the process)
>
> This code has been in Ant before I joined this list, so I can only
> guess why it works like it does.
>
> I'd be +1 on making the number of retries configurable (with only one
> try being the default?), a big +1 on not swallowing the IOException,
> but pass it up wrapped in the BuildException and +1 on adding a sleep
> attribute.
>
> -0 on removing the retry part completely - somebody seemed to need
> this.

I've looked at the code some more, and I dont believe that it has worked the
way it was intended.

The reason being that on line 128 there is a call to connect():-
            //connect to the remote site (may take some time)
            connection.connect();
            //next test for a 304 result (HTTP only)

if that call wasnt there then the call to connection.getInputStream() would
do the connect, bail out when there was trouble and then the multiple
retries and exception swallowing would kick in. But the connect() is
there -it has been there since before the iteration code was even added. And
unless someone with more source access than me can look at the
implementation of getInputStream() and see while it is likely to bail out
after a connection -the only cause I can see is the base classe's
UnknownServiceException() for protocols that dont support input- then the
iteration code isnt going to come in to play.

Maybe it works on protocols other than http; you try to connect to an http
site refusing connections and it only ever makes one try, not three.


To summarise: I dont think it is used. I'm leaving it alone right now, but
have much reworked the connect process to pave the way for digest auth.
retries could go in there if it was felt appropriate, but since people must
have got by without it, I'd rather leave it out.

-steve


Mime
View raw message