On Nov 6, 2007 4:41 PM, Merlijn van Deen valhallasw@arctus.nl wrote
What is important to consider is where the error correction is put. Some errors are recoverable after retry. The lower in level such a retry is placed, the less code duplication is required. However, retry code placed to low may cause to catch to generic errors.
'make sure you only catch errors you expect' :). In general, we should only catch errors that the user does not need to hear about. This means that even retry-after errors might need to traverse to the upper layer so the user at least gets a message 'Server load too high, retrying in ...'. If there is a way to get this information back to the user without backtracking completely, I'd like to hear :)
Wait callbacks:
def get_wait_token(self): token = hex(random.randint(0, sys.maxint)) self.wait_tokens[token] = 0 return token
def wait(self, token, reason): self.wait_callback(self.wait_tokens[token], reason) time.sleep(self.wait_tokens[token] * self.timeout) self.wait_tokens[token] += 1 ... site.wait_callback = lambda retry, reason: print 'Retry %s: %s' % (retry, reason) ...
token = site.get_wait_token() if 'Retry-After' in headers: self.wait(token, 'server lag') try_again()