On Fri, Aug 14, 2009 at 8:00 PM, David Anderson da...@ssl.berkeley.eduwrote:
I changed the file-transfer giveup time from 14 to 90 days.
-- David
Ticket 919 could now be closed: http://boinc.berkeley.edu/trac/ticket/919
___
boinc_dev mailing list
I just closed it, referencing r18845 in the comment.
On Sun, Aug 16, 2009 at 8:50 PM, Maureen Vilar mavi...@gmail.com wrote:
On Fri, Aug 14, 2009 at 8:00 PM, David Anderson da...@ssl.berkeley.edu
wrote:
I changed the file-transfer giveup time from 14 to 90 days.
-- David
Ticket 919
I don't see why this is needed.
If communication (RPC or file transfer) with a project is failing,
the client's backoff mechanisms should kick in and it should
stop trying to connect to that project.
If these mechanisms aren't working right,
let's fix them instead of adding a workaround.
If a
El Vie 14 Ago 2009 15:04:51 Lynn W. Taylor escribió:
It seems to me that the big fear is the two-week timer: if a work unit
can't be uploaded in two weeks, it's going to be thrown away, causing
irreparable harm to the project and a tragic hit to the cruncher's RAC.
It'd probably help to make
I changed the file-transfer giveup time from 14 to 90 days.
-- David
Lynn W. Taylor wrote:
It seems to me that the big fear is the two-week timer: if a work unit
can't be uploaded in two weeks, it's going to be thrown away, causing
irreparable harm to the project and a tragic hit to the
Lynn W. Taylor wrote
It seems to me that the big fear is the two-week timer: if a work unit
can't be uploaded in two weeks, it's going to be thrown away, causing
irreparable harm to the project and a tragic hit to the cruncher's RAC.
CPDN CM3-160 models can run for 4 months or longer. Losing
Richard,
You're agreeing with me.
There is a widespread perception that a lost upload causes irreperable
harm to the project, but as you point out, the work unit will just be
reassigned.
It's a waste of resources, and where possible waste *should* be avoided,
but it the error is handled
Lynn W. Taylor wrote:
[...]
As for the fact that the full upload has to complete before the error
comes back, that's as much an artifact of HTTP as anything else, and
can't be fixed without using something other than HTTP.
Include some mechanism to automatically break up large transfers into
