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

[Mark Sheppard]

On Thu, 27 Oct 2022 16:28:29 GMT, Darragh Clarke <duke at openjdk.org> wrote:

>> Added logging to SelectWhenRefused for an intermittent failure caused by unexpected wakeups, this includes trying to receive data if there is any available to identify where it is coming from.
>> 
>> I also set the test to run in othervm mode which should reduce the chances of this failure happening in the first place.
>
> Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added loop to retry in event of interruption from other tests

I think before making any majory changes to the test's execution in terms of respin etc,  the focus should be to add diagnostics to the test, to determine if there is actualy any data available and the origin of that unexpected data. Additionally, to check the verascity of the returned values from the selector, to esnure that the select has behaved in a consistent and reliable manner and that it has  not responded to indeterminate intermittent input (or other) event.

The test is open to ta race condition in  that the "refuser" port could have been resused by another socket in another concurrent test, after the DC1 has closed  -- this condition is tested in the test through a bind to refuser port, which is the failed scenarios has not rasied a BindException. But again timing is of the essence. 

I would suggest the initial focus for the changes should be for diagnostics of the failed scenario, and determing whether the selector returns actually reflect some input read event and not another spurious "low level event  trigger".

In the test the SelectionKey from the DC::register is not recorded, and not compared with the SelectionKey set returned by the selector. 
It would be informative if the number of keys returned by the select could be output. 
Currently in the test or in the updated logUnexpectedWakeup there is no check that the SelectioKey associated with the registered DC is actually returned. It is assumed that this is the case only a single channel has been registered, which is reasonable, but if consistency is to be deteremined then such a check may be worthwhile. Additionally, the registration is for READ events. Again,  it may be worth checking that the select has returned  SelectioKey for OP_READ and not something else.

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

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