Hi Daniel, wrt impl note ... would some explanation on the esoteric reason for a now possible BindException be useful, also? namely that on some platforms the socket is unbound during the disconnect and requires a re-bind, which for ephemeral ports allocated may result in a BindException.
try { statusUpdateDatagramChannel.disconnect(); } catch (IOException ioEx) { clientLogger.debug("Unexpected exception " + ioEx.getClass().getName(); statusUpdateDatagramChannel.close(); statusUpdateDatagramChannel = createStatusServiceDatagramChannel(); } ... the output will show a java.net.BindException, which is sort of arcane for a disconnect ? If it is strongly recommended to close the DatagramChannel, why not actually close the DatagramChannel in the event that the Net.bind throws a BindException ? I presume that on linux, if the port is not an OS chosen ephemeral port, i.e. it is a port from the registered port range that the reset of the port to 0 doesn't occur in a disconnect ? on the ln 947 localAddress = isa; if this was localAddress = null; would that allow a connect to be subsequently called and the DatagramChannel usable again, even when an BindException on the disconnect has occurred, as the DatagramChannel would be rebound by the connect ? In any case, I think it would be informative to disclose some further details on the possibility of a (re-)bind failure in the disconnect ! best regards Mark ________________________________ From: net-dev <net-dev-boun...@openjdk.java.net> on behalf of Daniel Fuchs <daniel.fu...@oracle.com> Sent: Monday 7 October 2019 11:34 To: Alan Bateman <alan.bate...@oracle.com>; nio-dev <nio-...@openjdk.java.net> Cc: OpenJDK Network Dev list <net-dev@openjdk.java.net> Subject: Re: RFR: 8231260: (dc) DatagramChannel::disconnect changes the port of the local address to 0 (lnx) Hi Alan, Here is the new webrev - I believe I have addressed all your comments: http://cr.openjdk.java.net/~dfuchs/webrev_8231260/webrev.01 best regards, -- daniel On 04/10/2019 14:55, Alan Bateman wrote: > On 04/10/2019 14:34, Daniel Fuchs wrote: >> : >> >> webrev: >> http://cr.openjdk.java.net/~dfuchs/webrev_8231260/webrev.00/ >> > The apiNote looks okay. DatagramChannelImpl::disconnect looks okay but I > assume "might not preserve" should be "does not preserve" (if you make > that change then the "This is the expected ..." line isn't needed). > > One suggestion is to rename the test to AddressesAfterDisconnect to make > it a bit clearer that it tests the local/remote addresses after > disconnect. I also assume we can change this to a TestNG test to avoid > the need for the assertXXX methods. > > -Alan.