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)
_______________________________________________
Mailing list: https://launchpad.net/~duplicity-team
Post to : [email protected]
Unsubscribe : https://launchpad.net/~duplicity-team
More help : https://help.launchpad.net/ListHelp
