RFR: 8293696: java/nio/channels/DatagramChannel/SelectWhenRefused.java fails with "Unexpected wakeup" [v2]

[Mark Sheppard]

On Thu, 27 Oct 2022 17:58:49 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Given the intermittent nature of the failure I'd rather do both at the same time. If we do receive a datagram, when we expect none, and we do verify that the datagram doesn't come from this test (it doesn't contain "Greetings!") then I'd argue that it must come from somewhere else (whatever that somewhere is) and it's safe to respin and try again.
> 
> There might be some subtle issues to fix in the retry logic though. I believe we should respin when getting unexpected wake ups only if we actually manage to read a datagram - for instance, and that we can assert that this datagram is not ours (and it should never be, since we sent it to a refuser that has a different port than our receiver). We should fail in all other cases.

I don't think it should matter what the source of the unexpected data is. 
The main issue for the failed scenario is that data may have been reeived.
If the test's sending DatagramChannel receives its own data, then that is a more problematic situation than if it is has received some data from an external UDP src. If it receives its own data then the DatagramChannel has had its data looped back, similar to what happens in multicast scenarios when IP_MULTICAST_LOOP is set on a DatagramChannel, and that channel sends to a multicast address. But  this is a directed send and that shouldn't happen. That wiuld all suggest anomalous behaviour at the OS level

Outputting the socket address of the sender would be helpful to determine if there is a possibility that any datagram originates from itself.

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

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