summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMonty Brandenberg <monty@lindenlab.com>2014-11-06 16:39:40 -0500
committerMonty Brandenberg <monty@lindenlab.com>2014-11-06 16:39:40 -0500
commitde9689e39beaea51db07b9ec60ddb106493b5c28 (patch)
tree87bf2e449efda1e336e00a21b80d9c05242f0a1a
parent02e2235277a90f2e291557a429ae4e5de3e0d3b6 (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-xindra/llcorehttp/_httpoprequest.cpp17
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;