On Tue, 20 Dec 2022 10:37:34 GMT, Daniel Fuchs <dfu...@openjdk.org> wrote:
>> src/java.net.http/share/classes/jdk/internal/net/http/ResponseSubscribers.java
>> line 291:
>>
>>> 289: long n = out.write(buffers);
>>> 290: if (n <= 0) {
>>> 291: throw new IOException("zero bytes written");
>>
>> "Returns: The number of bytes written, possibly zero"
>>
>> Sorry for being dumb, but why is the returned zero bytes treated as an
>> error? If I were to write a fuzzifier for that class, it'd be my first thing
>> on the to do list to randomly return zero bytes - if the contract allows it,
>> it should be handled gracefully.
>
> Well this has the potential of creating a busy loop since bytesWritten will
> not increase if zero is returned.
I know that. But write should eventually make progress - even if it spins a few
times. What's the point of having that JDK method explicitly state "may return
0" and then disregarding that as something that is an exceptional scenario? I
don't see the consistency here... If it can return zero, fine - handle it by
retrying. If this code falls into a spin loop and never makes progress - this
would be a problem somewhere else (perhaps in the implementation of the file
channel), not here.
-------------
PR: https://git.openjdk.org/jdk/pull/11722
