3 ms·
Used B2 heavily until recently as a origin server for a CDN. Few weeks ago we saw a spike in 502 / 504 responses. When I contacted their customer supported ,
by ing33k 6y ago
Used B2 heavily until recently as a origin server for a CDN.
Few weeks ago we saw a spike in 502 / 504 responses.
When I contacted their customer supported , I was pointed to the following URL where they explain in detail how they handle these errors
https://www.backblaze.com/blog/b2-503-500-server-error/ https://www.backblaze.com/blog/b2-503-500-server-error/
Essentially they are not considered as errors and expect the client to retry loading the file. This approach won't work in our use case.
- Shakahs 6y agoIf you are using Cloudflare you could use a Worker script to automatically retry the origin pull and only cache it on success.
- tgtweak 6y agoYou can definitely get read errors and your application should be aware of this and handle this use case. Amazon's own S3 is not immune to this and after years of running spark jobs which shard output across thousands of files on s3 (and load from the same) you'll see these underlying http errors on a daily scale even intra-region. Even if you're doing multi region s3 replication you'll run into this for external clients semi-occasionally.
- TickleSteve 6y agoSo, you're relying on the API being 100% reliable? no errors?
- ing33k 6y agoI not expecting 100 % reliability. but when we get a 503 response it should be considered an an error and acknowledged by the provider that it's an error. in my use case, we were using a CDN which was configured to pull files from B2. When B2 responds with a 503/500 I have no control on the retry mechanism. The error rate was around 5-10%
- nacs 6y agoRetrying a failed network request seems like a normal thing to do -- whether its a network timeout, server error, or whatever random hiccup happened.