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

[Mark Sheppard]

On Tue, 8 Nov 2022 16:01:18 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:
> 
>   Use Junit for tests

Using the setup strategy would be in keeping with junit idioms, but it is debatable if it is worth it here (i'm not advocating it).
If you were to use the junit setUp, then I think it would be more appropriately applied on the class 

    private static DatagramChannel dc;
    private static Selector sel;
    private static SocketAddress refuser;
    private static int port;
    

    @BeforeAll
    static void setupClass () {
    // test fixture resources setup
   }


    @AfterAll
    static void tearDownClass () {
       // close resources

   }

then your test fixtures become 
DatagramChannel dc, 
SocketAddress refuser, 
Selector sel,
int port
 which would reduce the parameters passed to each  test scenario method. But you'll have to handle any setup failures in the  setup method and barf if there are any problems, also. Where as what you have now  the test will just fail if any setup exceptions are encountered.

I think the test as one logical unit is best, because then the test has to handle the allocation of a ephemeral refuser port only once. But note that ephemeral refuser port is available for re-allocation by the OS for the duration of the test, and not just the initial test scenario where an OS re-allocation is tested. If the second connected scenario does not raise a PUE, then refuser port re-allocation could be a contributing factor, that is, the delivery of a datagram to an extant UDP end point. Again, it should be stated that this has not been the observed failure, but rather the unexpected wakeup in scenario 1 no PUE unconnected.

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

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