dgit.raspbian.org Git - git-annex.git/blob

   1 [[!comment format=mdwn
   2  username="joey"
   3  subject="""comment 1"""
   4  date="2018-03-24T13:54:31Z"
   5  content="""
   6 Note that with --retry 10, curl will back off 10 times, with wait doubling,
   7 so it could get stuck for 20+ minutes. That seems too long, but the right
   8 number of retries seems to depend on how overloaded the http server is; you
   9 may need a number that would otherwise be excessive in order to get a high
  10 enough probability of success.
  11
  12 Also worth noting that http *has* status codes such as 503 that are
  13 intended to be used when the client should wait and retry; 500 is not such
  14 a code.
  15
  16 If this is done at the wget/curl level, it will also need to be done
  17 when using the http-client library (which does not currently retry on any
  18 code, AFAICs).
  19
  20 And, it could just as easily be a S3 or webdav server that is throwing the
  21 http retry codes, and the libraries for those will have their own retrying
  22 behavior. (And it could even be a ssh server ot other non-http protocol
  23 that connections to fail intermittently.)
  24
  25 Putting all this together, I'm wondering if the http level is the right
  26 place to put this retrying. It's not a matter of complying with the http
  27 spec; it seems to need user configuration in order to handle their
  28 particular use case.
  29
  30 git-annex already does generic retrying as long as some data was
  31 received, to recover from broken connections. That could be extended to
  32 support a config option that enables a number of retries.
  33 """]]