duplicity-team team mailing list archive

[Michael Terry <michael.terry@xxxxxxxxxxxxx>]

Michael Terry has proposed merging lp:~mterry/duplicity/always-delay into lp:duplicity.

Requested reviews:
  duplicity-team (duplicity-team)

For more details, see:
https://code.launchpad.net/~mterry/duplicity/always-delay/+merge/87909

I've noticed some occasional odd SSL errors with the U1 backend that seemed transient, but with the current retry logic, we just hammer the server 5 times in a row instantly upon an error.  It made me think that all errors, it doesn't hurt to give a server some breathing room on the order of 10s.  It's not going to slow down operation much (since errors are the exception not the rule) and on odd server goofs, we buy ourselves some robustness.
-- 
https://code.launchpad.net/~mterry/duplicity/always-delay/+merge/87909
Your team duplicity-team is requested to review the proposed merge of lp:~mterry/duplicity/always-delay into lp:duplicity.

=== modified file 'duplicity/backend.py'
--- duplicity/backend.py	2011-10-08 15:55:26 +0000
+++ duplicity/backend.py	2012-01-09 09:14:24 +0000
@@ -313,7 +313,9 @@
                 log.Debug("Backtrace of previous error: %s"
                           % exception_traceback())
                 if isinstance(e, TemporaryLoadException):
-                    time.sleep(30) # wait a bit before trying again
+                    time.sleep(30) # wait longer before trying again
+                else:
+                    time.sleep(10) # wait a bit before trying again
         # Now try one last time, but fatal-log instead of raising errors
         kwargs = {"raise_errors" : False}
         return fn(*args, **kwargs)