RFR: 8259628: jdk/net/ExtendedSocketOption/AsynchronousSocketChannelNAPITest.java fails intermittently [v4]

[Mark Sheppard]

On Fri, 22 Jan 2021 14:41:44 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8259628: Removed buffer check
>
> You could still do some checking if you wanted.
> If you know that you have written `nsent` bytes, and that you later read `nread` bytes, then you could assert the following:
> 1. nread <= nsent
> 2. writeBuffer.mismatch(readBuffer) == (nread == nsent ? -1 : nread)

Hi Daniel,
   by adding a read/send bytes checks, are we not obscuring the purpose of the test and that's the NAPI check ?
Consider that, as the communication channel between the writer and sender is a stream, there are no (atomic) message boundaries, and in theory a read could be less than an individual write in one iteration,  and then greater than the individual write in another iteration. Thus, adding an assert could give rise to unnecessary failures - it is unlikely in this test - in fact because of colocation you could place a strong bet that it won't happen. 
Nonetheless, the following is possible
iteration N      write n bytes, reads m where  m < n (The underlying TCP protocol machine has sent m bytes and not the full n)
iteration N +1  write n bytes, read n + (n-m)  i.e. the current write + the residue from the write in iteration N

and then an  assert nread <= nsent will fail  ?

In any case, the main thing is that the test is happy with its NAPI across the various reads

best regards
Mark

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

PR: https://git.openjdk.java.net/jdk/pull/2162