8231259: (dc) DatagramChannel::disconnect re-binds socket to the wildcard address (macOS)

[Daniel Fuchs]

Hi Alan,

This looks very good to me.

DatagramChannelImpl:

I wonder however if:

1177                     InetSocketAddress isa = Net.localAddress(fd);

should be

                          InetSocketAddress isa = localAddress =
                                                  Net.localAddress(fd);

In case repairSocket() later fails. Although we already specified
that "the socket is an unspecified state", it would leave
the socket is in an unspecified state closer to what it was
before the fix.

1222             Object value = getOption(option);
1223             if (value != null) {
1224                 map.put(option, value);
1225             }

Should we catch and ignore IOException thrown by getOption(),
there - as you did in the test?

MembershipRegistry:

  123     interface ThrowingConsumer<T, X extends Throwable> {...

should that be annotated with @FunctionalInterface?

Otherwise looks great!

best regards,

-- daniel


On 15/11/2019 08:37, Alan Bateman wrote:
> This issue is a corner case on macOS where a DatagramChannel is 
> initially bound to a specific address, connected, and disconnect is 
> called to dissolve the association. This scenario is problematic on BSD 
> and macOS systems because disconnect re-binds the socket to the wildcard 
> address. I brought up this issue on the bsd-port-dev a few months ago 
> [1] where Kurt Miller replied to say that he has a patch for OpenBSD to 
> fix this. Daniel Fuchs submitted a bug to Apple, tracked as FB7330899, 
> on the macOS issue, but no news yet on if/when this will be fixed.
> 
> In the mean-time, we are continuing the effort to fix the various issues 
> needed to replace the legacy implementation of DatagramSocket and 
> MulticastSocket. I mentioned this in a recent mail [2] as it's the 
> motivation for many of the recent changes/fixes to the DatagramChannel 
> implementation and its adaptor. Those on net-dev will see related 
> changes from Patrick Concannon and Daniel to DatagramSocket and 
> MulticastSocket so that it will be ready for a new implementation. The 
> overall effort runs into the macOS bug. The reason that it is not 
> observed with legacy DatagramSocket is because it works around it by 
> emulating connected sockets on macOS, an approach that doesn't make 
> sense for DatagramChannel (as it is a selectable change). For 
> DatagramChannel we considering a temporary workaround re-create the 
> underlying socket on buggy kernels. "Re-create" means creating a new 
> socket, using dup2 to re-plumb the original to the new socket, and then 
> restoring the local address, multicast membership, selector 
> registrations and socket options. Any of these steps can fail but this 
> should be okay as the javadoc makes it clear that disconnect failing can 
> leave the channel's socket in an unspecified state.
> 
> The webrev with the proposed change is here. The test that Daniel added 
> as part of JDK-8231260 has been re-purposed to be a much broader test.
> 
>    http://cr.openjdk.java.net/~alanb/8231259/webrev/
> 
> -Alan
> 
> [1] 
> https://mail.openjdk.java.net/pipermail/bsd-port-dev/2019-September/003215.html 
> 
> [2] 
> https://mail.openjdk.java.net/pipermail/nio-dev/2019-November/006775.html