RFR: 8332535: Mark java/nio/channels/DatagramChannel/Loopback.java as intermittent

[SendaoYan]

On Mon, 20 May 2024 16:53:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> No objection to add the keyword. From a quick look at the logs then it hints that it may be a kernel issue rather than a JDK issue, e.g. here one of the failures in the logs you attached:
> 
> ```
> UNSPEC socket
> join ff02:0:0:0:0:0:0:a @ veth87b01b2
> set outgoing multicast interface to veth87b01b2
> IP_MULTICAST_LOOP enabled
> send /[0:0:0:0:0:0:0:0]:50287 -> /[ff02:0:0:0:0:0:0:a]:50287
> received java.nio.HeapByteBuffer[pos=5 lim=100 cap=100] from /[fe80:0:0:0:8cf3:1bff:fe85:f8e6%5]:50287
> IP_MULTICAST_LOOP disabled
> send /[0:0:0:0:0:0:0:0]:50287 -> /[ff02:0:0:0:0:0:0:a]:50287
> selected 1
> received java.nio.HeapByteBuffer[pos=5 lim=5 cap=100] from /[fe80:0:0:0:8cf3:1bff:fe85:f8e6%5]:50287
> STDERR:
> java.lang.RuntimeException: Unexpected message
> ```
> 
> I assume veth87b01b2 is a virtual interface. When IP_MULTICAST_LOOP is enabled the 5-byte multicast datagram is looped as expected. When IP_MULTICAST_LOOP is disabled then it appears to be looped again. So this may require digging into the kernel to better understand this. It would be interesting to know if it's always IPv6 where the failures happen.

I reporduced this intermittent failure on a ECS, so veth87b01b2 is a virtual interface. I will close IPv6 and reproduce this failure. After I close IPv6, and this failure can not repoeduce, then maybe the failure alway happend in IPv6.

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

PR Comment: https://git.openjdk.org/jdk/pull/19314#issuecomment-2121522844