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)
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
To: "Ant Developers List" <dev@ant.apache.org>
References: <5849cb7112b8b3b052d7bc4c468171e8@d6.nl>
 <871uu54moj.fsf@v35516.1blu.de>
Date: Mon, 24 Oct 2011 15:26:39 +0200
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: AVee <avee@avee.org>
Message-ID: <op.v3uyapb0f3h4fl@arjanhp.bwaste.local>
In-Reply-To: <871uu54moj.fsf@v35516.1blu.de>
User-Agent: Opera Mail/11.51 (Win32)
Subject: Re: [PATCH] Add retryDelay to the retry task

On Sat, 22 Oct 2011 07:31:24 +0200, Stefan Bodewig <bodewig@apache.org>  
wrote:

> Hi Arjan,

...

> I know that I have used retry logic in totally different circumstances
> in code where I increased the delay with each retry attempt.  I.e. I
> waited a very short time before the first retry and doubled it each
> time.  Would something like this make sense here as well?

The thought crossed my mind, but I didn't do this because (for me at  
least) the number of retries is always going to be very limited.
When the number of retries is limited the total time you're going to be  
retrying is going to be relatively low, I guess the increment won't make a  
big difference in that case. Personally I wouldn't want my build scripts  
to spend 10 minutes retrying something, but if you think there's a use for  
it I could build it. Should be easy enough.

> It would be good if you could open an enhancement request in bugzilla
> and attach your patch.  It is less prone to get lost there compared to
> the developers' INBOX.

There you go: https://issues.apache.org/bugzilla/show_bug.cgi?id=52076

Regards,
Arjan Veenstra

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