RFR: 8310807: java/nio/channels/DatagramChannel/Connect.java timed out [v2]

[Jaikiran Pai]

On Tue, 14 Nov 2023 18:01:44 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please find here a fix for a timeout issue observed in DatagramChannel/Connect.java
>> 
>> The suspicion is that the responder may have received some message from some other source and replied to that, leaving the initiator waiting forever.
>> 
>> The proposed fix makes sure the messages exchanged are unique and identifiable and ensure that both the initiator and responder will discard any message that do not have the expected content.
>> 
>> Additional logging should help with diagnosis if the test fails again.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor cleanup 3

test/jdk/java/nio/channels/DatagramChannel/Connect.java line 160:

> 158:                     if (!RESPONSE.equals(cb.toString())) {
> 159:                         log.println("Initiator received unexpected message: continue waiting");
> 160:                         continue;

`DatagramChannel.read(ByteBuffer)`, through the contract of `ReadableByteChannel.read(ByteBuffer)`, says that the number of bytes added into the passed `ByteBuffer` may not always be the remaining space in the buffer. i.e. `dc.read(bb)` may just read in few bytes at a time.

Do you think that's a practical possibility in the context of this test and would that then mean, in this current proposed form, the `RESPONSE.equals(cb.toString())` will never evaluate to `true` and we would end up looping forever?

Perhaps we should use the return value of `dc.read(bb)` to determine when to do this response equality check and until then keep accumulating the received bytes?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16661#discussion_r1395712782