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 <[email protected]> on behalf of Daniel Fuchs
<[email protected]>
Sent: Monday 7 October 2019 11:34
To: Alan Bateman <[email protected]>; nio-dev <[email protected]>
Cc: OpenJDK Network Dev list <[email protected]>
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.
