diff options
| author | Monty Brandenberg <monty@lindenlab.com> | 2014-09-04 16:57:44 -0400 |
|---|---|---|
| committer | Monty Brandenberg <monty@lindenlab.com> | 2014-09-04 16:57:44 -0400 |
| commit | 0c20beda6800149ee71a307ca4e943b5bba56908 (patch) | |
| tree | 504ed9a9816a11022801e25334b5f4431f54744e /indra/newview/llmeshrepository.cpp | |
| parent | 7fa382937679a9937fd7b09e33b6c2f39ec680ff (diff) | |
Pipelining work. Extend transfer timeout by the pipeline depth
as transfers can appear delayed with deep pipelining and more
requests in the pool. Added bad HTTP status error (typically
getting a 0 back as HTTP status from libcurl) to the list of
retryable errors. There's a response stream problem with libcurl
and pipelining that induces this problem. Retrying helps but
may not be entirely safe. Watch bug 1420 on the libcurl sourceforge
bug tracker. Extend options of test/example program to include
un-ranged requests. Document the excessive data transfer induced
when ranged requests are disabled. This is an abnormal mode for
very rare users so we'll just eat that for now.
Diffstat (limited to 'indra/newview/llmeshrepository.cpp')
| -rwxr-xr-x | indra/newview/llmeshrepository.cpp | 13 |
1 files changed, 12 insertions, 1 deletions
diff --git a/indra/newview/llmeshrepository.cpp b/indra/newview/llmeshrepository.cpp index 6477389d4c..a6707392fe 100755 --- a/indra/newview/llmeshrepository.cpp +++ b/indra/newview/llmeshrepository.cpp @@ -2644,6 +2644,17 @@ void LLMeshRepository::cacheOutgoingMesh(LLMeshUploadData& data, LLSD& header) } +// Handle failed or successful requests for mesh assets. +// +// Support for 200 responses was added for several reasons. One, +// a service or cache can ignore range headers and give us a +// 200 with full asset should it elect to. We also support +// a debug flag which disables range requests for those very +// few users that have some sort of problem with their networking +// services. But the 200 response handling is suboptimal: rather +// than cache the whole asset, we just extract the part that would +// have been sent in a 206 and process that. Inefficient but these +// are cases far off the norm. void LLMeshHandlerBase::onCompleted(LLCore::HttpHandle handle, LLCore::HttpResponse * response) { mProcessed = true; @@ -2685,7 +2696,7 @@ void LLMeshHandlerBase::onCompleted(LLCore::HttpHandle handle, LLCore::HttpRespo if (par_status == status) { - // 216 case + // 206 case response->getRange(&offset, &length, &full_length); if (! offset && ! length) { |