ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
Subject Re: cvs commit: ant/docs/manual/OptionalTasks ftp.html
Date Wed, 01 Jun 2005 21:34:20 GMT
Steve Cohen wrote:
> Steve Loughran wrote:
>> wrote:
>>> scohen      2005/05/29 17:40:21
>>>   Modified:    src/testcases/org/apache/tools/ant/taskdefs/optional/net
>>>                src/main/org/apache/tools/ant/taskdefs/optional/net 
>>>                src/etc/testcases/taskdefs/optional/net ftp.xml
>>>                docs/manual/OptionalTasks ftp.html
>>>   Added:       src/main/org/apache/tools/ant/util
>>>   Log:
>>>   Based on a patch submitted by Neeme Praks, allow support for a 
>>> retry count on FTP transfers.  Some
>>>   servers are unreliable for unknown - this allows for a retry count 
>>> to be specified to accomodate work on such
>>>   flaky servers.
>> nice. Are you doing any kind of back-off algorithm to deal with load 
>> problems? If so, add a bit of jitter to increase the randomness. (I 
>> remember an embedded system without back-off but not jitter failing to 
>> deal with the situation of an entire building with 120+ nodes having 
>> its power toggled...)
>> -steve
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> I'm not entirely sure what you mean.  By "jitter", are you referring to 
> varying the time delay?  I asked Neeme Praks why he didn't put in a time 
> delay and he said he didn't need one.  In his use case, he simply sets 
> it up to run forever, and that works for him.  Eventually it succeeds. 
> But I wonder about this.  Sounds like it could be a tight loop that eats 
> all processing under the wrong conditions.
> And I'm not sure at all what you mean by a "back-off algorithm".

> So please elaborate.

Ethernet is the example: when there is a collision, they back off by 
waiting a time, say "t". IF there is a collision then, they wait t*2, 
then t*4, t*8, etc until it gets through. The reason for the exponential 
delay is to deal with a congested network/host, etc.
Implementations have to put some slight jitter in so that two 
synchronise nodes dont continually collide.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message