RFR: 8299015: Ensure that HttpResponse.BodySubscribers.ofFile writes all bytes

[Dawid Weiss]

On Mon, 19 Dec 2022 14:02:41 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> The implementation of `BodySubscribers.ofFile` does not correctly handle the case of a short gathering write. The write should be retried until all the bytes have been written to the underlying file.
> 
> This is generally not an issue that would occur very frequently, since the `IOV_MAX` is commonly 1024 on Mac/Linux, and 16 on Windows. However, it is clearly a bug, and should be fixed.

This approximates and reproduces my original scenario, if you're curious,
Daniel:
https://gist.github.com/dweiss/9703cfa2713a7fc211a0018a72267d90

I get something like this in the output:
Corrupted line received: 683
Corrupted line received: 351
Corrupted line received: line: 2662
Corrupted line received: ne: 4628
Corrupted line received: 8560
Missed line range: 16-683
Missed line range: 699-930
Missed line range: 947-1351
Missed line range: 1367-1396
Missed line range: 1413-1574
... [lots more]

Dawid


On Mon, Dec 19, 2022 at 6:25 PM Daniel Fuchs ***@***.***>
wrote:

> Ah! I see. A big byte buffer read from the socket might be split into a
> list of small ByteBuffer chunks at the higher level, when parsing HTTP/1.1
> chunks.
>
> I managed to intermittently reproduce this on my Mac, by hacking on the
> test - not pretty. I guess the test could be updated to try to provoke this
> with the HTTP Client, but it doesn't seem worth it, if we accept that it
> just needs to be fixed.
>
> I agree that there's no need. The test you have is enough and appropriate
> for the fix.
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/openjdk/jdk/pull/11722#issuecomment-1357998214>, or
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AABQWLRB5B44DMNJJIHZ5GTWOCLATANCNFSM6AAAAAATDMUIUM>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>

-------------

PR: https://git.openjdk.org/jdk/pull/11722