Aggressively retry downloads

[concourse]

Aggressively retry downloads

[concourse-bot]

Hi there!

We use Pivotal Tracker to provide visibility into what our team is working on. A story for this issue has been automatically created.

The current status is as follows:

• #131016671 Aggressively retry downloads

This comment, as well as the labels on the issue, will be automatically updated as the status in Tracker changes.

[zachgersh]

@vito can do - saw this and was intrigued that it even happened.

[zachgersh]

Was waiting to accumulate at least two issues before I started work again.

[zachgersh]

@vito one half (retry failed http, like connection timeout is done).

41250ed

io.EOF check coming next.

[zachgersh]

@vito fixed for both retryable http errors and unexpect EOFs (a bit more than what you asked but nice nonetheless).

[ljfranklin]

@zachgersh I have the perfect test for this feature. We have a Concourse worker in China that has to download a 500MB stemcell from bosh.io. Even when using the CloudFront URL, it just failed 5 times in a row with "TLS handshake timeout", then "read: connection timed out", followed by a few "read: connection reset by peer". Hopefully these fall under "Temporary" errors.

Gonna build a Docker image from master and put the retries through their paces :)

[zachgersh]

Yesssss! Please reopen if you find it doesn't actually work. This will
retry infinitely so be prepared to kill the task as needed!

On Thursday, November 3, 2016, Lyle Franklin [email protected]
wrote:

@zachgersh https://github.com/zachgersh I have the perfect test for
this feature. We have a Concourse worker in China that has to download a
500MB stemcell from bosh.io. Even when using the CloudFront URL, it just
failed 5 times in a row with "TLS handshake timeout", then "read:
connection timed out", followed by a few "read: connection reset by peer".
Hopefully these fall under "Temporary" errors.

Gonna build a Docker image from master and put the retries through their
paces :)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#13 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAqFAxE4TrkfbUQMln0TtmvZvgLkSt-8ks5q6kZXgaJpZM4KFa-y
.

[ljfranklin]

@zachgersh so we should probably re-open this. All the download attempts failed with "request canceled (Client.Timeout exceeded while reading body)". The 5 minute timeout here is way too low for the China download unfortunately. I'm trying it again with the Timeout set to 0. Any specific reason the 5 minute timeout was introduced? The DefaultTransport would still give some lower-level handshake and idle connection timeouts, so the connection shouldn't hang forever even if the HTTP Client Timeout is 0.

[zachgersh]

@ljfranklin - can we open a new issue to remove that timeout? I can totally get rid of it now that I introduced a different fake :/