RFR: JDK-8286610: Add additional diagnostic output to java/net/DatagramSocket/InterruptibleDatagramSocket.java [v2]

[Mark Sheppard]

On Mon, 27 Jun 2022 16:16:47 GMT, Bill Huang <duke at openjdk.org> wrote:

>> Failure was observed on java/net/DatagramSocket/InterruptibleDatagramSocket.java where data was received unexpectedly ( [JDK-8286607](https://bugs.openjdk.org/browse/JDK-8286607)). This failure could be caused by interference from other ongoing tests. The fix here is to output the unexpected received data and the sender's address for a further investigation ([JDK-8286610](https://bugs.openjdk.org/browse/JDK-8286610)).
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rephrased debug messages.

test/jdk/java/net/DatagramSocket/InterruptibleDatagramSocket.java line 111:

> 109:         }
> 110:         try (DatagramSocket s = DatagramChannel.open().socket()) {
> 111:             System.out.println("Testing interrrupt of DatagramChannel socket " +

I just noticed that this System out will return a null address:
Testing interrrupt of DatagramChannel socket receive on endpoint null
This shows an anomalies between DatagramChannel and DatagramSocket in that an explicit bind is usually required for DC. In this case when the receive is invoked there will be an implicit bind to wildcard and ephemeral port  ... The test could be changed to invoke bind(null) on the created DC, maybe as follows:

       try (DatagramChannel dc = DatagramChannel.open().bind(null)) {
            System.out.println("Testing interrrupt of DatagramChannel socket " +
                    "receive on endpoint " + dc.getLocalAddress());
            test(dc.socket(), true);
        }

This will give the informed output
Testing interrrupt of DatagramChannel socket receive on endpoint /[0:0:0:0:0:0:0:0]:54572

which trivially highlight a triple r in interrrupt

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

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