[MERGE] [BUG #165061] Force http.readv() to a maximum number of range requests.
Vincent Ladeuil
v.ladeuil+lp at free.fr
Thu Nov 29 16:29:45 GMT 2007
>>>>> "john" == John Arbash Meinel <john at arbash-meinel.com> writes:
<snip/>
john> I think you could get rid of that in sftp even. It was just a workaround for an
john> earlier version of paramiko which assumed that your requests would always fit.
john> so 1.5.2 would need it, but 1.6+ doesn't (IIRC).
>>
>> Thanks for confirming that (I was a bit surprised when looking at
>> both sftp.py* and paramiko), I just committed an adapted version
>> that takes care of out of order offsets and transient errors.
>>
>> No tests yet and no http response rewriting, so memory
>> consumption may be worse in some cases which were failing before
>> the patch.
>>
>> Onn the other hand, it also fix bug #172071, so I'll continue on
>> that one.
john> I think you need to check your bugs. I'm pretty sure this is a typo:
john> https://bugs.launchpad.net/bzr/+bug/172071
john> Especially since the bug is written in Spanish.
john> You probably meant:
john> https://bugs.edge.launchpad.net/bzr/+bug/172701
>>
>> Vincent
>>
>> *: You may want to clean up the code and the comments then ?
>>
john> *I* want to do no such thing. :) But I'm happy to approve a patch.
Not *the* sftp expert myself ;-)
john> This may not be the best location to have the comment but:
john> # The sftp spec says that implementations SHOULD allow reads
john> # to be at least 32K. paramiko.readv() does an async request
john> # for the chunks. So we need to keep it within a single request
john> # size for paramiko <= 1.6.1. paramiko 1.6.2 will probably chop
john> # up the request itself, rather than us having to worry about it
john> _max_request_size = 32768
john> Which is right at the beginning of SFTPTransport.
john> certainly we could add that as step (8) in the _sftp_readv() comment.
and update step (2) which mention 65536 (a bit disturbing).
No urgency anyway.
Vincent
More information about the bazaar
mailing list