Try all download servers when multiple URLs are supplied by the project. This is needed because the first download server may be unreachable or out of sync which produces a permanent error. Uploads are handled differently and always use the transient_failure() function.
With old (7.15) versions of libcurl, args passed to curl_easy_setopt()
(such as the URL) were supposed to remain unchanged until
the operation was done.
Starting with 7.17 it was changed so that curl_easy_setopt()
copied its arguments.
The BOINC client was assuming the latter.
When linked against the former,
URLs would mysteriously change to garbage strings.
I changed things to work with the old libcurl semantics.
A while back we added a mechanism intended to defer work-request RPCs
while file uploads are happening,
with the goal of reporting completed tasks sooner
and reducing the number of RPCs.
There were 2 bugs in this mechanism.
First, the decision of whether an upload is active was flawed;
if several uploads were active and 1 finished,
it would act like all had finished.
Second, when WORK_FETCH::choose_project.cpp() picks a project,
it sets p->sched_rpc_pending to RPC_REASON_NEED_WORK.
If we then decide not to request work because an upload
is active, we need to clear this field.
Otherwise scheduler_rpc_poll() will do an RPC to it,
piggybacking a work request and bypassing the upload check.
(usually in a static variable called "last_time")
of the last time we did something,
and we only do it again when now - last_time exceeds some interval.
Example: sending heartbeat messages to apps.
Problem: if the system clock is decreased by X,
we won't do any of these actions are time X,
making it appear that the client is frozen.
Solution: when we detect that the system clock has decreased,
set a global var "clock_change" for 1 iteration of the polling loop,
and disable these time checks if clock_change is set.
not just when a result becomes ready to upload.
Fix bug where a scheduler RPC to report results is done
even though uploads are active.
- client: cpu_sched_debug enables messages about not scheduling jobs
because of insufficient RAM
svn path=/trunk/boinc/; revision=25493
so that we can fetch work immediately
- client: in PERS_FILE_XFER::create_xfer(),
check for already-existing file before seeing we're allowed to start a new xfer
- client: in PERS_FILE_XFER::create_xfer(),
if an async verify is in progress, mark PERS_FILE_XFER as done.
svn path=/trunk/boinc/; revision=25243
File verify is done in 4 places:
- after a download finishes
- transition result to DOWNLOADED
- if project->verify_files_on_app_start, on app start
Use asynchrony only in the first 2 cases,
since the async logic is set up to mark the file as PRESENT
when done, not to restart a task
svn path=/trunk/boinc/; revision=25219
an upgrade from 6.12 to 6.13+,
it could get erroneously marked as an upload and get stuck forever.
Problem: uninitialized member.
svn path=/trunk/boinc/; revision=24744
within PERS_FILE_XFER::transient_failure();
we're about to delete and free the FILE_XFER.
The transfer will be restarted in the next poll.
svn path=/trunk/boinc/; revision=24549
where the client crashes after giving up (90 day timeout) on an upload.
I'm guessing this was caused by [24391],
which changed the order in the poll loop from
garbage_collect
file_xfers->poll
pers_file_xfers->poll
handle_pers_file_xfers
to
garbage_collect
handle_pers_file_xfers
file_xfers->poll
pers_file_xfers->poll
I don't understand why this would have caused a crash,
but so be it.
I restored the original order, but with handle_pers_file_xfers
not inside the if (!network_suspended).
- client renamed handle_pers_file_xfers() to
create_and_delete_pers_file_xfers()
- client simulator: show simulator CPU time
svn path=/trunk/boinc/; revision=24531
and one of them is down.
If several downloads from the broken one fail,
we go into "project-level backoff"
and don't start downloads from either server.
(Same applies to uploads).
Solution: make project-level backoff apply only to
transfers that have already failed at least once
svn path=/trunk/boinc/; revision=24339
as described here: http://boinc.berkeley.edu/trac/wiki/ClientDataModel
Compatibility:
clients that upgrade to this version should see nothing unusual.
Clients that downgrade from this version to a previous version
should see all projects reset
(i.e. tasks disappear and then get re-downloaded).
- manager: always show whether a file transfer is upload or download
- client: don't scale work requests by resource share
svn path=/trunk/boinc/; revision=23862
(since we may have been waiting for upload finish)
- client: fix crash: if remove an RSS feed, remove its active HTTP op if any.
svn path=/trunk/boinc/; revision=23097
and an upload started in the last 5 min, don't fetch work from it.
The goal is to merge the 2 scheduler RPCs
(fetch work, report completed taskS) into a single RPC.
Note: this may result in idleness in some cases.
- scheduler: if client doesn't handle plan class (pre-5.10),
check plan-class app versions anyway,
but only use if it's a single-CPU app.
This allows single-CPU app versions with specific requirements
(like SSE) to be issued to old clients.
From Bernd Machenschalk
svn path=/trunk/boinc/; revision=22841
apply same random backoff to all transfers.
- client: when changing ncpus via config file,
don't modify host_info.p_ncpus
- client: show effective #CPUs separately from physical #
svn path=/trunk/boinc/; revision=21470
favor those that are partially done
- client: fix crashing bug if a project is detached
while an RSS feed fetch for it is in progress
- code cleanup: switch from /// back to // for comments
(so much for doxygen)
svn path=/trunk/boinc/; revision=21041
that way it will query server for file length when it resumes,
rather than uploading from the beginning
- client: back out SEH handling for GPU detection
svn path=/trunk/boinc/; revision=20750
- client: (refinement to previous checkin)
don't skip file size check if file has multiple upload URLs.
We might have uploaded different amounts on different servers.
svn path=/trunk/boinc/; revision=18606
Old: each upload attempt consists of two HTTP requests:
the 1st to get the current file size on server,
the 2nd to upload the remainder of the file.
Problem:
a) if the upload server is overloaded and requests
are succeeding with probability X,
then the chance of both requests succeeding is X^2.
So e.g. a per-request success rate of 0.1
becomes an overall success rate of 0.01.
b) the "get file size" request can be avoided in some cases.
New:
If we've already queried the file size
and haven't uploaded any additional bytes,
don't query the file size again.
svn path=/trunk/boinc/; revision=18605
uploads and downloads.
I originally added this on 30 Sept 2005
and disabled it 2 weeks later because there were reports of problems.
However, we need this functionality
(e.g. on GPU hosts with hundreds of files to upload,
we need to back off after a few failures, not try all of them).
I added messages (<file_xfer_debug>) so you can see what's going on.
Fixes#932.
svn path=/trunk/boinc/; revision=18593
Christian Beer