diff options
author | Monty Brandenberg <monty@lindenlab.com> | 2014-11-06 16:39:40 -0500 |
---|---|---|
committer | Monty Brandenberg <monty@lindenlab.com> | 2014-11-06 16:39:40 -0500 |
commit | de9689e39beaea51db07b9ec60ddb106493b5c28 (patch) | |
tree | 87bf2e449efda1e336e00a21b80d9c05242f0a1a | |
parent | 02e2235277a90f2e291557a429ae4e5de3e0d3b6 (diff) |
BUG-7698, BUG-7688, BUG-7694 (others) CDN connection issues.
Under pipelining, requests were given a 5x timeout factor due to the
way that the timeout clock works in libcurl. Under CDN load,
connections were not being torn down quickly and it was only
this timer that led to disconnect and retry. So, we want to
break a connection that isn't making progress but that isn't
immediately possible. We'll compromise with a 60S timeout that
(we hope) will be neither too long for stalled connections nor
too short for large asset transfer requests.
-rwxr-xr-x | indra/llcorehttp/_httpoprequest.cpp | 17 |
1 files changed, 16 insertions, 1 deletions
diff --git a/indra/llcorehttp/_httpoprequest.cpp b/indra/llcorehttp/_httpoprequest.cpp index fbbb1614fb..7482a89dac 100755 --- a/indra/llcorehttp/_httpoprequest.cpp +++ b/indra/llcorehttp/_httpoprequest.cpp @@ -623,8 +623,23 @@ HttpStatus HttpOpRequest::prepareRequest(HttpService * service) // a handwave but bump the transfer timeout up by the pipelining // depth to give some room. // + // BUG-7698, BUG-7688, BUG-7694 (others). Scylla and Charybdis + // situation. Operating against a CDN having service issues may + // lead to requests stalling for an arbitrarily long time with only + // the CURLOPT_TIMEOUT value leading to a closed connection. Sadly + // for pipelining, libcurl (7.39.0 and earlier, at minimum) starts + // the clock on this value as soon as a request is started down + // the wire. We want a short value to recover and retry from the + // CDN. We need a long value to safely deal with a succession of + // piled-up pipelined requests. + // // *TODO: Find a better scheme than timeouts to guarantee liveness. - xfer_timeout *= cpolicy.mPipelining; + // Progress on the connection is what we really want, not timeouts. + // But we don't have access to that and the request progress indicators + // (various libcurl callbacks) have the same problem TIMEOUT does. + // + // xfer_timeout *= cpolicy.mPipelining; + xfer_timeout *= 2L; } // *DEBUG: Enable following override for timeout handling and "[curl:bugs] #1420" tests // xfer_timeout = 1L; |