Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

acme (189)

acme
  (email not shown publicly)
http://www.astray.com/

Leon Brocard (aka acme) is an orange-loving Perl eurohacker with many varied contributions to the Perl community, including the GraphViz module on the CPAN. YAPC::Europe was all his fault. He is still looking for a Perl Monger group he can start which begins with the letter 'D'.

Journal of acme (189)

Thursday February 28, 2008
11:46 AM

Retries in Net::Amazon::S3

[ #35788 ]
One of the slight issues with Amazon's Simple Storage Service is that by design sometimes the service returns a HTTP 500 Internal Server Error response and the client should retry the request. Previously, applications which use my Net::Amazon::S3 module, such as Brackup, had to handle the retries themselves - but no more! With the magic that is LWP::UserAgent::Determined you can now pass a retry option into the version 0.42 of Net::Amazon::S3 and it will handle the retries with exponential backoff for you.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Thanks a lot for this, Leon. I'm so happy I don't have to implement this on my own now.
  • Why Exponential and not Fibonacci? It probably won't matter in real life (since it will only take a single retry), but I think Fibonacci is the generally preferred algorithm. Exponential gets unreasonable after just a few iterations. (16 seconds, then 32 seconds?)
    • Mostly because it's the one Amazon recommend. Many retries aren't often necessary, Amazon S3 for Science Grids: a Viable Solution (PDF) [usf.edu] mentions:

      We have observed an availability rate of 99.03% after the original download attempt, 99.55% after the first retry and a full 100% availability after two retries. Additional retries were never needed during the observed period. These results are convergent with Amazon's stated 99.99% availability target.