Merge lp:~jameinel/bzr/2.5-unending-sendall-1047309 into lp:bzr/2.5
Status: | Merged |
---|---|
Approved by: | John A Meinel |
Approved revision: | no longer in the source branch. |
Merged at revision: | 6510 |
Proposed branch: | lp:~jameinel/bzr/2.5-unending-sendall-1047309 |
Merge into: | lp:bzr/2.5 |
Diff against target: |
68 lines (+34/-1) 3 files modified
bzrlib/osutils.py (+5/-1) bzrlib/tests/test_osutils.py (+22/-0) doc/en/release-notes/bzr-2.5.txt (+7/-0) |
To merge this branch: | bzr merge lp:~jameinel/bzr/2.5-unending-sendall-1047309 |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Richard Wilbur | Needs Fixing | ||
Martin Packman (community) | Approve | ||
Review via email: mp+123268@code.launchpad.net |
Commit message
Detect if we are not progressing during osutils.send_all() and fail rather than hang. (bug #1047309)
Description of the change
See the associated bug #1047309.
Basically, with the new ConnectionReset code coming into bzr-2.5, it seems that if Paramiko gets disconnected, it is unable to send any content, but doesn't raise an error. (it returns 0 bytes sent, but no exception is raised.)
As a conservative fix, this allows us to get a series of up to 5 0-bytes-sent, but any more than that in a row, and we just treat it as a ECONNRESET. Looking at the man pages, it seems send in non-blocking socket shouldn't ever give 0 bytes sent, but I preferred to be a little cautious.
If this causes fallout, we could tweak the retries, or even do sleep-based backoff.
Did you find any answer on if it's valid for send() to return 0? As far as I'm aware it's not, it's either EINTR or a partial write of more than one byte, though I can't find anything explicit either.
For implementations like paramiko that just emulate the interface, coping with this is I guess required, though it would be nice to fix upstream to do something more sane. I'd prefer raising an error straight off, but understand the motivation behind retying several times, as that would previously have worked and regressions are bad. I'd much prefer not to use this heuristic if at possible though, instead quirking on the socket type or something that makes it explict this is a paramiko issue only.