Integrated: 8285671: java/nio/channels/etc/PrintSupportedOptions.java and java/nio/channels/DatagramChannel/AfterDisconnect.java are failing

ated. Changeset: ef27081f Author:Michael McMahon URL: https://git.openjdk.java.net/jdk/commit/ef27081fe7e00c8ec8e21d3ee31d7194b5339da2 Stats: 96 lines in 7 files changed: 91 ins; 3 del; 2 mod 8285671: java/nio/channels/etc/PrintSupportedOptions.java and java/nio/channels/DatagramChannel

Re: RFR: 8285671: java/nio/channels/etc/PrintSupportedOptions.java and java/nio/channels/DatagramChannel/AfterDisconnect.java are failing [v2]

On Wed, 27 Apr 2022 14:27:01 GMT, Michael McMahon wrote: >> src/jdk.net/macosx/native/libextnet/MacOSXSocketOptions.c line 209: >> >>> 207: return JNI_FALSE; >>> 208: } >>> 209: fd = socket(AF_INET6, SOCK_DGRAM, 0); >> >> So if IPv6 is not supported on the machine, won't that re

Re: RFR: 8285671: java/nio/channels/etc/PrintSupportedOptions.java and java/nio/channels/DatagramChannel/AfterDisconnect.java are failing [v3]

On Wed, 27 Apr 2022 14:57:34 GMT, Michael McMahon wrote: >> Hi, >> >> Can I get the following fix reviewed please? JDK-8284890 was pushed >> yesterday and is causing failures on older versions of macOS that do not >> support the option. The fix here is to check at initialization time whether

Re: RFR: 8285671: java/nio/channels/etc/PrintSupportedOptions.java and java/nio/channels/DatagramChannel/AfterDisconnect.java are failing [v2]

On Wed, 27 Apr 2022 14:12:40 GMT, Daniel Fuchs wrote: >> Michael McMahon has updated the pull request incrementally with one >> additional commit since the last revision: >> >> updated test > > test/jdk/jdk/net/ExtendedSocketOption/DontFragmentTest.java line 44: > >> 42: >> 43: public s

Re: RFR: 8285671: java/nio/channels/etc/PrintSupportedOptions.java and java/nio/channels/DatagramChannel/AfterDisconnect.java are failing [v3]

> Hi, > > Can I get the following fix reviewed please? JDK-8284890 was pushed yesterday > and is causing failures on older versions of macOS that do not support the > option. The fix here is to check at initialization time whether it is > supported before adding it to the list of supported opti

Re: RFR: 8285671: java/nio/channels/etc/PrintSupportedOptions.java and java/nio/channels/DatagramChannel/AfterDisconnect.java are failing [v2]

On Wed, 27 Apr 2022 14:10:55 GMT, Daniel Fuchs wrote: >> Michael McMahon has updated the pull request incrementally with one >> additional commit since the last revision: >> >> updated test > > src/jdk.net/macosx/native/libextnet/MacOSXSocketOptions.c line 209: > >> 207: return JNI_F

Re: RFR: 8285671: java/nio/channels/etc/PrintSupportedOptions.java and java/nio/channels/DatagramChannel/AfterDisconnect.java are failing [v2]

On Wed, 27 Apr 2022 12:10:13 GMT, Michael McMahon wrote: >> Hi, >> >> Can I get the following fix reviewed please? JDK-8284890 was pushed >> yesterday and is causing failures on older versions of macOS that do not >> support the option. The fix here is to check at initialization time whether

Re: RFR: 8285671: java/nio/channels/etc/PrintSupportedOptions.java and java/nio/channels/DatagramChannel/AfterDisconnect.java are failing [v2]

> Hi, > > Can I get the following fix reviewed please? JDK-8284890 was pushed yesterday > and is causing failures on older versions of macOS that do not support the > option. The fix here is to check at initialization time whether it is > supported before adding it to the list of supported opti

Re: RFR: 8285671: java/nio/channels/etc/PrintSupportedOptions.java and java/nio/channels/DatagramChannel/AfterDisconnect.java are failing

On Wed, 27 Apr 2022 11:02:08 GMT, Daniel Fuchs wrote: >> Hi, >> >> Can I get the following fix reviewed please? JDK-8284890 was pushed >> yesterday and is causing failures on older versions of macOS that do not >> support the option. The fix here is to check at initialization time whether >>

Re: RFR: 8285671: java/nio/channels/etc/PrintSupportedOptions.java and java/nio/channels/DatagramChannel/AfterDisconnect.java are failing

On Wed, 27 Apr 2022 09:43:52 GMT, Michael McMahon wrote: > Hi, > > Can I get the following fix reviewed please? JDK-8284890 was pushed yesterday > and is causing failures on older versions of macOS that do not support the > option. The fix here is to check at initialization time whether it is

Re: RFR: 8285671: java/nio/channels/etc/PrintSupportedOptions.java and java/nio/channels/DatagramChannel/AfterDisconnect.java are failing

On Wed, 27 Apr 2022 09:43:52 GMT, Michael McMahon wrote: > Hi, > > Can I get the following fix reviewed please? JDK-8284890 was pushed yesterday > and is causing failures on older versions of macOS that do not support the > option. The fix here is to check at initialization time whether it is

Re: RFR: 8285671: java/nio/channels/etc/PrintSupportedOptions.java and java/nio/channels/DatagramChannel/AfterDisconnect.java are failing

On Wed, 27 Apr 2022 09:43:52 GMT, Michael McMahon wrote: > Hi, > > Can I get the following fix reviewed please? JDK-8284890 was pushed yesterday > and is causing failures on older versions of macOS that do not support the > option. The fix here is to check at initialization time whether it is

RFR: 8285671: java/nio/channels/etc/PrintSupportedOptions.java and java/nio/channels/DatagramChannel/AfterDisconnect.java are failing

Hi, Can I get the following fix reviewed please? JDK-8284890 was pushed yesterday and is causing failures on older versions of macOS that do not support the option. The fix here is to check at initialization time whether it is supported before adding it to the list of supported options. The err

Re: RFR[8240533]: 'Inconsistent Exceptions are thrown by DatagramSocket and DatagramChannel when sending a DatagramPacket to port 0.'

> On 04/04/2020 16:26, Patrick Concannon wrote: >> Hi Chris and Daniel, >> Well spotted, Chris. Thanks for that! >> Thanks too Daniel, that's a good idea. I've made those changes and included >> them in a new webrev, which you can find below. >> http://cr.openjdk.java.net/~pconcannon/8240533/we

Re: RFR[8240533]: 'Inconsistent Exceptions are thrown by DatagramSocket and DatagramChannel when sending a DatagramPacket to port 0.'

Looks good to me Patrick! best regards, -- daniel On 04/04/2020 16:26, Patrick Concannon wrote: Hi Chris and Daniel, Well spotted, Chris. Thanks for that! Thanks too Daniel, that's a good idea. I've made those changes and included them in a new webrev, which you can find below. http://cr

Re: RFR[8240533]: 'Inconsistent Exceptions are thrown by DatagramSocket and DatagramChannel when sending a DatagramPacket to port 0.'

Hi Patrick, This looks good to me.. Best Lance > On Apr 4, 2020, at 11:26 AM, Patrick Concannon > wrote: > > Hi Chris and Daniel, > > > Well spotted, Chris. Thanks for that! > > Thanks too Daniel, that's a good idea. I've made those changes and included > them in a new webrev, which you

Re: RFR[8240533]: 'Inconsistent Exceptions are thrown by DatagramSocket and DatagramChannel when sending a DatagramPacket to port 0.'

Hi Chris and Daniel, Well spotted, Chris. Thanks for that! Thanks too Daniel, that's a good idea. I've made those changes and included them in a new webrev, which you can find below. http://cr.openjdk.java.net/~pconcannon/8240533/webrevs/webrev.02/ Kind regards, Patrick On 03/04/2020 17:

Re: RFR[8240533]: 'Inconsistent Exceptions are thrown by DatagramSocket and DatagramChannel when sending a DatagramPacket to port 0.'

Hi Patrick, 120 { perms.add(new SocketPermission("127.0.0.1:0", 121 "connect,accept")); } 122 { perms.add(new SocketPermission("0.0.0.0:0", 123 "connect,accept")); } there in other tests - I think a single permission: { perms.add(new Socke

Re: RFR[8240533]: 'Inconsistent Exceptions are thrown by DatagramSocket and DatagramChannel when sending a DatagramPacket to port 0.'

The new webrev can be found here: > http://cr.openjdk.java.net/~pconcannon/8240533/webrevs/webrev.01/
> 
> I have just a few more minor comments: I think there is a small cut’n’paste issue with test/jdk/java/nio/channels/DatagramChannel/SendPortZero.java 59 * @run testng/oth

Re: RFR[8240533]: 'Inconsistent Exceptions are thrown by DatagramSocket and DatagramChannel when sending a DatagramPacket to port 0.'

Hi, Thanks for the feedback. 

 Lance - I swapped out expectThrows for assertThrows, as requested. Chris - I put in an extra check in the tests to ensure that the new code doesn’t interfere with the Security Manager checks already present in the source. The new webrev can be found here: ht

Re: 8241786: 3 DatagramChannel tests and 2 MulticastSocket tests fail due to "SocketException: No buffer space available"

On 03/04/2020 12:04, Daniel Fuchs wrote: Hi Alan, Hopefully that's fixed now. Only change is in AdaptorMulticasting.java http://cr.openjdk.java.net/~dfuchs/webrev_8241786/webrev.03 Thanks, looks good. -Alan

Re: 8241786: 3 DatagramChannel tests and 2 MulticastSocket tests fail due to "SocketException: No buffer space available"

Hi Alan, Hopefully that's fixed now. Only change is in AdaptorMulticasting.java http://cr.openjdk.java.net/~dfuchs/webrev_8241786/webrev.03 best regards, -- daniel On 02/04/2020 09:56, Alan Bateman wrote: All I'm asking is that additional tracing being consistent with the existing traces. St

Re: 8241786: 3 DatagramChannel tests and 2 MulticastSocket tests fail due to "SocketException: No buffer space available"

Daniel, > On 2 Apr 2020, at 10:33, Daniel Fuchs wrote: > > Hi Chris, > > On 02/04/2020 09:40, Chris Hegarty wrote: >> This is a functional change that affects the product build. Maybe that >> would be a little clearer from a different bug synopsis. Suggest >> something like: >> Improve heuris

Re: 8241786: 3 DatagramChannel tests and 2 MulticastSocket tests fail due to "SocketException: No buffer space available"

Hi Chris, On 02/04/2020 09:40, Chris Hegarty wrote: This is a functional change that affects the product build. Maybe that would be a little clearer from a different bug synopsis. Suggest something like: Improve heuristic to determine default network interface on macOS I can do that - or I

Re: 8241786: 3 DatagramChannel tests and 2 MulticastSocket tests fail due to "SocketException: No buffer space available"

On 02/04/2020 09:48, Daniel Fuchs wrote: : DefaultInterface might be better in a test infra class (in java/net) to avoid duplicate it in several tests. I have considered that. The problem is that it requires the test that uses it to add @modules java.base/java.net:+open directive in the te

Re: 8241786: 3 DatagramChannel tests and 2 MulticastSocket tests fail due to "SocketException: No buffer space available"

it - so there is no duplication (yet). Maybe we should wait until we need it elsewhere before thinking of ways to move it to the test library? The updates to the DatagramChannel tests look okay but I think we should change the new trace messages added to AdaptorMulticasting to be consistent with

Re: 8241786: 3 DatagramChannel tests and 2 MulticastSocket tests fail due to "SocketException: No buffer space available"

Daniel, > On 1 Apr 2020, at 18:42, Daniel Fuchs wrote: > > Hi, > > Please find below a fix for: > > 8241786: 3 DatagramChannel tests and 2 MulticastSocket tests > fail due to "SocketException: No buffer space available" > https://bugs.openjdk.java

Re: 8241786: 3 DatagramChannel tests and 2 MulticastSocket tests fail due to "SocketException: No buffer space available"

On 01/04/2020 18:42, Daniel Fuchs wrote: Hi, Please find below a fix for: 8241786: 3 DatagramChannel tests and 2 MulticastSocket tests fail due to "SocketException: No buffer space available" https://bugs.openjdk.java.net/browse/JDK-8241786 webrev: http://cr.openjd

8241786: 3 DatagramChannel tests and 2 MulticastSocket tests fail due to "SocketException: No buffer space available"

Hi, Please find below a fix for: 8241786: 3 DatagramChannel tests and 2 MulticastSocket tests fail due to "SocketException: No buffer space available" https://bugs.openjdk.java.net/browse/JDK-8241786 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8241786/webrev.01/ The r

Re: RFR[8240533]: 'Inconsistent Exceptions are thrown by DatagramSocket and DatagramChannel when sending a DatagramPacket to port 0.'

Patrick, > On 31 Mar 2020, at 15:08, Daniel Fuchs wrote: > >> .. >> bug: https://bugs.openjdk.java.net/browse/JDK-8240533 >> webrev: http://cr.openjdk.java.net/~pconcannon/8240533/webrevs/webrev.00/ Look good Patrick. The check is deliberately performed after the security manager checks, right

Re: RFR[8240533]: 'Inconsistent Exceptions are thrown by DatagramSocket and DatagramChannel when sending a DatagramPacket to port 0.'

aniel On 31/03/2020 11:15, Patrick Concannon wrote: Hi, Could someone please review my fix for JDK-8240533 'Inconsistent Exceptions are thrown by DatagramSocket and DatagramChannel when sending a DatagramPacket to port 0.' ? Currently, DatagramSocket throws an IOException when se

Re: RFR[8240533]: 'Inconsistent Exceptions are thrown by DatagramSocket and DatagramChannel when sending a DatagramPacket to port 0.'

On 31/03/2020 11:15, Patrick Concannon wrote: Hi, Could someone please review my fix for JDK-8240533 'Inconsistent Exceptions are thrown by DatagramSocket and DatagramChannel when sending a DatagramPacket to port 0.' ? Currently, DatagramSocket throws an IOException when sending

Re: RFR[8240533]: 'Inconsistent Exceptions are thrown by DatagramSocket and DatagramChannel when sending a DatagramPacket to port 0.'

gt; > Hi, > > Could someone please review my fix for JDK-8240533 'Inconsistent Exceptions > are thrown by DatagramSocket and DatagramChannel when sending a > DatagramPacket to port 0.' ? > > Currently, DatagramSocket throws an IOException when sending to port

RFR[8240533]: 'Inconsistent Exceptions are thrown by DatagramSocket and DatagramChannel when sending a DatagramPacket to port 0.'

Hi, Could someone please review my fix for JDK-8240533 'Inconsistent Exceptions are thrown by DatagramSocket and DatagramChannel when sending a DatagramPacket to port 0.' ? Currently, DatagramSocket throws an IOException when sending to port 0, and doesn't throw

Re: RFR[8234812]: 'Add micros for DatagramChannel send/receive'

Hi, Thanks for the feedback Chris and Alan. I've added an boolean parameter to the benchmark to allow for the use of a direct ByteBuffer -- true for direct, false for heap. In interest of keeping the run time of the benchmark down, I've only included a 'true' value. However, 'false' can be ad

Re: RFR[8234812]: 'Add micros for DatagramChannel send/receive'

On 13/02/2020 16:53, Chris Hegarty wrote: : Did you intentionally use heap byte buffers, or should the test use direct buffers? That is a good discussion point as there is a matrix of heap vs. direct, blocking vs. non-blocking, scatter/gather, ... that could be added to create more comprehens

Re: RFR[8234812]: 'Add micros for DatagramChannel send/receive'

> On 13 Feb 2020, at 14:27, Patrick Concannon > wrote: > > Hi, > > > Could someone please review my webrev for JDK-8234812 'Add micros for > DatagramChannel send/receive' ? > > This test adds some benchmarks for the DatagramChannel's send, re

RFR[8234812]: 'Add micros for DatagramChannel send/receive'

Hi, Could someone please review my webrev for JDK-8234812 'Add micros for DatagramChannel send/receive' ? This test adds some benchmarks for the DatagramChannel's send, receive, read and write methods. bug: https://bugs.openjdk.java.net/browse/JDK-82348

Re: 8237896: MulticastSocket should link to DatagramChannel as an alternative for multicasting.

On 29/01/2020 16:18, Daniel Fuchs wrote: Hi Alan. Alright. I've transformed the second note in an @see: http://cr.openjdk.java.net/~dfuchs/webrev_8237896/webrev.02/ This looks okay to me. -Alan

Re: 8237896: MulticastSocket should link to DatagramChannel as an alternative for multicasting.

Hi Alan. Alright. I've transformed the second note in an @see: http://cr.openjdk.java.net/~dfuchs/webrev_8237896/webrev.02/ best regards, -- daniel On 29/01/2020 08:20, Alan Bateman wrote: If someone has a MulticastSocket then they can't get to a DatagramChannel to use the altern

Re: 8237896: MulticastSocket should link to DatagramChannel as an alternative for multicasting.

On 28/01/2020 11:22, Daniel Fuchs wrote: I'm not sure I understand why obtaining a MulticastChannel from a DatagramSocket is important. Maybe the wording needs to be clarified? If someone has a MulticastSocket then they can't get to a DatagramChannel to use the alternative join meth

Re: 8237896: MulticastSocket should link to DatagramChannel as an alternative for multicasting.

37896/webrev.01 + * @apiNote A better alternative to join multicast groups is provided + * by the {@code join} methods defined in the {@link MulticastChannel} + * interface implemented by {@link DatagramChannel}. + * Condider using {@code DatagramChan

Re: 8237896: MulticastSocket should link to DatagramChannel as an alternative for multicasting.

On 27/01/2020 19:14, Daniel Fuchs wrote: Hi, Please find below a doc-only fix for: 8237896: MulticastSocket should link to DatagramChannel as an alternative for multicasting. https://bugs.openjdk.java.net/browse/JDK-8237896 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8237896

8237896: MulticastSocket should link to DatagramChannel as an alternative for multicasting.

Hi, Please find below a doc-only fix for: 8237896: MulticastSocket should link to DatagramChannel as an alternative for multicasting. https://bugs.openjdk.java.net/browse/JDK-8237896 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8237896/webrev.00/ best regards, -- daniel

Re: RFR[8236105]: Behaviors of DatagramSocket/DatagramChannel::socket send methods are not always consistent

haviors of DatagramSocket/DatagramChannel::socket send methods are not always consistent' ? The behaviour of the send methods for DatagramSocket, MulticastSocket, DatagramChannel and DatagramSocketAdaptor are not consistent when given a DatagramPacket with invalid details. This fix

Re: RFR[8236105]: Behaviors of DatagramSocket/DatagramChannel::socket send methods are not always consistent

> On 17 Jan 2020, at 12:50, Patrick Concannon > wrote: > > Hi Chris, > > > > Thanks for your feedback. I've created a related bug for the points you've > raised and I will take a look at them once this issue has been fixed. > > The new issue be found here: https://bugs.openjdk.java.net/b

Re: RFR[8236105]: Behaviors of DatagramSocket/DatagramChannel::socket send methods are not always consistent

:03, Chris Hegarty wrote: Patrick, On 13 Jan 2020, at 16:30, Patrick Concannon mailto:patrick.concan...@oracle.com>> wrote: Hi, Could someone please review my fix and CSR for issue JDK-8236105 'Behaviors of DatagramSocket/DatagramChannel::socket send methods are not always consiste

Re: RFR[8236105]: Behaviors of DatagramSocket/DatagramChannel::socket send methods are not always consistent

Patrick, > On 13 Jan 2020, at 16:30, Patrick Concannon > wrote: > > Hi, > > Could someone please review my fix and CSR for issue JDK-8236105 'Behaviors > of DatagramSocket/DatagramChannel::socket send methods are not always > consistent' ? > &g

Re: 8236925: (dc) Upgrade DatagramChannel socket adaptor to extend MulticastSocket

> On 16 Jan 2020, at 12:10, Alan Bateman wrote: > > On 16/01/2020 11:45, Chris Hegarty wrote: >> : >> Generally, I agree with updating the socket adapter to support >> multicast. It will certainly help with future work in this area. >> >> The instanceof checks in the constructors highlight tha

Re: 8236925: (dc) Upgrade DatagramChannel socket adaptor to extend MulticastSocket

On 16/01/2020 11:45, Chris Hegarty wrote: : Generally, I agree with updating the socket adapter to support multicast. It will certainly help with future work in this area. The instanceof checks in the constructors highlight that there is an abstraction missing here - to support creating a custom

Re: 8236925: (dc) Upgrade DatagramChannel socket adaptor to extend MulticastSocket

> On 14 Jan 2020, at 19:23, Alan Bateman wrote: > > ... > Here's the updated webrev that changes oldImpl to be final. >http://cr.openjdk.java.net/~alanb/8236925/2/webrev/ Generally, I agree with updating the socket adapter to support multicast. It will certainly help with future work in t

Re: RFR[8236105]: Behaviors of DatagramSocket/DatagramChannel::socket send methods are not always consistent

my fix and CSR for issue JDK-8236105 'Behaviors of DatagramSocket/DatagramChannel::socket send methods are not always consistent' ? The behaviour of the send methods for DatagramSocket, MulticastSocket, DatagramChannel and DatagramSocketAdaptor are not consistent when given a Data

Re: 8236925: (dc) Upgrade DatagramChannel socket adaptor to extend MulticastSocket

Looks good Alan! best regards. -- daniel On 14/01/20 19:23, Alan Bateman wrote: Thanks for going through this. I tried to keep the changes to DatagramSocket to a minimum but I don't mind making an exception for oldImpl. It's a slippery slope as there is a lot of technical debt in this area.

Re: 8236925: (dc) Upgrade DatagramChannel socket adaptor to extend MulticastSocket

On 14/01/2020 17:49, Daniel Fuchs wrote: Hi Alan, Globally this looks good to me. One small nit is that the `oldImpl` field could now also become final (by applying the same trick you did with createImpl - that is - have oldImpl() return a boolean rather than set the field and assign the result

Re: 8236925: (dc) Upgrade DatagramChannel socket adaptor to extend MulticastSocket

your patch and am currently running some tests. best regards, -- daniel On 10/01/2020 14:55, Alan Bateman wrote: This is a patch to "upgrade" the DatagramChannel socket adaptor to extend MulticastSocket. This is one of the final changes needed to DatagramChannel and its socket adapto

RFR[8236105]: Behaviors of DatagramSocket/DatagramChannel::socket send methods are not always consistent

Hi, Could someone please review my fix and CSR for issue JDK-8236105 'Behaviors of DatagramSocket/DatagramChannel::socket send methods are not always consistent' ? The behaviour of the send methods for DatagramSocket, MulticastSocket, DatagramChannel and DatagramSocketAdapt

8236925: (dc) Upgrade DatagramChannel socket adaptor to extend MulticastSocket

This is a patch to "upgrade" the DatagramChannel socket adaptor to extend MulticastSocket. This is one of the final changes needed to DatagramChannel and its socket adaptor buddy to make it easy to replace the legacy DatagramSocket and MulticastSocket implementation. Daniel has a dr

Re: RFR[8231570]: (dc) Clarify implicit bind behavior of DatagramChannel

> On 16 Oct 2019, at 19:20, Patrick Concannon > wrote: > > [Resending with nio-dev in cc] > > Hi, > > > Could someone please review my fix and CSR for issue JDK-8231570 '(dc) > Clarify implicit bind behavior of DatagramChannel' ? >

Re: RFR[8231570]: (dc) Clarify implicit bind behavior of DatagramChannel

'(dc) Clarify implicit bind behavior of DatagramChannel' ? The fix clarifies the security checks for DatagramChannel connect, send, and receive methods. webrev: http://cr.openjdk.java.net/~pconcannon/8231570/webrevs/webrev.02/ CSR: https://bugs.openjdk.java.net/browse/JDK-82323

Re: RFR[8231570]: (dc) Clarify implicit bind behavior of DatagramChannel

On 16/10/2019 19:20, Patrick Concannon wrote: : webrev: http://cr.openjdk.java.net/~pconcannon/8231570/webrevs/webrev.02/ Looks good.

RFR[8231570]: (dc) Clarify implicit bind behavior of DatagramChannel

[Resending with nio-dev in cc] Hi, Could someone please review my fix and CSR for issue JDK-8231570 '(dc) Clarify implicit bind behavior of DatagramChannel' ? The fix clarifies the security checks for DatagramChannel connect, send, and receive methods. webrev: http://cr.openjd

RFR[8231570]: (dc) Clarify implicit bind behavior of DatagramChannel

Hi, Could someone please review my fix and CSR for issue JDK-8231570 '(dc) Clarify implicit bind behavior of DatagramChannel' ? The fix clarifies the security checks for DatagramChannel connect, send, and receive methods. webrev: http://cr.openjdk.java.net/~pconcannon/82315

Re: RFR: 8231260: (dc) DatagramChannel::disconnect changes the port of the local address to 0 (lnx)

Hi Mark, On 09/10/2019 10:44, mark sheppard wrote: Would it be instantaneously available after its release by the kernel, or subject to TTL lifetime? The fact that DatagramSocket has been doing that for years and that we haven't had any issue so far suggests that the case where rebind would fa

Re: RFR: 8231260: (dc) DatagramChannel::disconnect changes the port of the local address to 0 (lnx)

: 8231260: (dc) DatagramChannel::disconnect changes the port of the local address to 0 (lnx) On 08/10/2019 15:29, Alan Bateman wrote: > On 08/10/2019 15:20, mark sheppard wrote: >> : >> >> Q: is localAddress.getPort() == 0 indicative that the >> DatagramChannel is unb

Re: RFR: 8231260: (dc) DatagramChannel::disconnect changes the port of the local address to 0 (lnx)

On 08/10/2019 15:29, Alan Bateman wrote: On 08/10/2019 15:20, mark sheppard wrote: : Q: is  localAddress.getPort() == 0   indicative that the DatagramChannel is unbound ? getLocalAddress() returns a SocketAddress when bound, it returns null when not bound. I don't think we should ge

Re: RFR: 8231260: (dc) DatagramChannel::disconnect changes the port of the local address to 0 (lnx)

On 08/10/2019 15:20, mark sheppard wrote: : Q: is localAddress.getPort() == 0 indicative that the DatagramChannel is unbound ? getLocalAddress() returns a SocketAddress when bound, it returns null when not bound. I don't think we should get too hung up on corner case that arises whe

Re: RFR: 8231260: (dc) DatagramChannel::disconnect changes the port of the local address to 0 (lnx)

port ? Q: is localAddress.getPort() == 0 indicative that the DatagramChannel is unbound ? best regards Mark From: Daniel Fuchs Sent: Tuesday 8 October 2019 09:16 To: mark sheppard ; Alan Bateman ; nio-dev Cc: OpenJDK Network Dev list Subject: Re: RFR: 8231260: (dc) DatagramChannel

Re: RFR: 8231260: (dc) DatagramChannel::disconnect changes the port of the local address to 0 (lnx)

such a thing as over specification for a dark system specific corner case of the API. The CSR [1] and release notes [2] should have enough documentation without engraving such details in stone in the Java SE specification. If it is strongly recommended to close the DatagramChannel, why not actually

Re: RFR: 8231260: (dc) DatagramChannel::disconnect changes the port of the local address to 0 (lnx)

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

Re: RFR: 8231260: (dc) DatagramChannel::disconnect changes the port of the local address to 0 (lnx)

* Daniel Fuchs: > Here is the new webrev - I believe I have addressed all your comments: > > http://cr.openjdk.java.net/~dfuchs/webrev_8231260/webrev.01 Looks good to me too. Sorry for the distraction earlier. Thanks, Florian

Re: RFR: 8231260: (dc) DatagramChannel::disconnect changes the port of the local address to 0 (lnx)

> On 7 Oct 2019, at 12:34, Daniel Fuchs wrote: > > 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 Looks good Daniel. -Chris

Re: RFR: 8231260: (dc) DatagramChannel::disconnect changes the port of the local address to 0 (lnx)

On 07/10/2019 12:34, Daniel Fuchs wrote: 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 Thanks for the update, this version looks good to me. -Alan.

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

Re: RFR: 8231260: (dc) DatagramChannel::disconnect changes the port of the local address to 0 (lnx)

* Alan Bateman: > On 04/10/2019 17:03, Florian Weimer wrote: >> : >> The kernel will do it atomically during connect, so there is no race >> condition. With the change above, the port is selected and opened, >> packets can arrive (from arbitrary addresses), and only then the socket >> is bound to

Re: RFR: 8231260: (dc) DatagramChannel::disconnect changes the port of the local address to 0 (lnx)

* Daniel Fuchs: > Hi Florian, > > On 04/10/2019 16:25, Florian Weimer wrote: >> Doesn't it introduce a race condition where the socket has a port and >> queue packets, but the kernel will not perform source address checking >> because it is unconnected? > > The long standing behavior of DatagramSo

Re: RFR: 8231260: (dc) DatagramChannel::disconnect changes the port of the local address to 0 (lnx)

On 04/10/2019 17:03, Florian Weimer wrote: : The kernel will do it atomically during connect, so there is no race condition. With the change above, the port is selected and opened, packets can arrive (from arbitrary addresses), and only then the socket is bound to the remote address. I don't se

Re: RFR: 8231260: (dc) DatagramChannel::disconnect changes the port of the local address to 0 (lnx)

* Florian Weimer: > * Alan Bateman: > >> On 04/10/2019 16:25, Florian Weimer wrote: >>> : >>> @@ -873,10 +873,15 @@ >>> synchronized (stateLock) { >>> ensureOpen(); >>> if (state == ST_CONNECTED) >>> throw new

Re: RFR: 8231260: (dc) DatagramChannel::disconnect changes the port of the local address to 0 (lnx)

Hi Florian, On 04/10/2019 16:25, Florian Weimer wrote: Doesn't it introduce a race condition where the socket has a port and queue packets, but the kernel will not perform source address checking because it is unconnected? The long standing behavior of DatagramSocket::connect is to throw out a

Re: RFR: 8231260: (dc) DatagramChannel::disconnect changes the port of the local address to 0 (lnx)

* Alan Bateman: > On 04/10/2019 16:25, Florian Weimer wrote: >> : >> @@ -873,10 +873,15 @@ >> synchronized (stateLock) { >> ensureOpen(); >> if (state == ST_CONNECTED) >> throw new AlreadyConnectedException();

Re: RFR: 8231260: (dc) DatagramChannel::disconnect changes the port of the local address to 0 (lnx)

On 04/10/2019 16:25, Florian Weimer wrote: : @@ -873,10 +873,15 @@ synchronized (stateLock) { ensureOpen(); if (state == ST_CONNECTED) throw new AlreadyConnectedException(); +// ensure t

Re: RFR: 8231260: (dc) DatagramChannel::disconnect changes the port of the local address to 0 (lnx)

* Daniel Fuchs: > Hi, > > Please find below a fix for: > > 8231260: (dc) DatagramChannel::disconnect changes the port of the > local address to 0 (lnx) > https://bugs.openjdk.java.net/browse/JDK-8231260 I remember looking at this a couple of years ago. I was mostl

Re: RFR: 8231260: (dc) DatagramChannel::disconnect changes the port of the local address to 0 (lnx)

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 m

Re: RFR: 8231260: (dc) DatagramChannel::disconnect changes the port of the local address to 0 (lnx)

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 exp

RFR: 8231260: (dc) DatagramChannel::disconnect changes the port of the local address to 0 (lnx)

Hi, Please find below a fix for: 8231260: (dc) DatagramChannel::disconnect changes the port of the local address to 0 (lnx) https://bugs.openjdk.java.net/browse/JDK-8231260 The nature of the fix introduces an unlucky (though unlikely) case where an exception might get thrown which

Re: RFR[8230946]: Clarify security manager behaviour of a connected DatagramSocket and DatagramChannel

On 02/10/2019 11:16, Patrick Concannon wrote: Hi Daniel, Well spotted. I've fixed that now, and updated the webrev. Looks good.

Re: RFR[8230946]: Clarify security manager behaviour of a connected DatagramSocket and DatagramChannel

Hi Daniel, Well spotted. I've fixed that now, and updated the webrev. Kind regards, Patrick On 02/10/2019 11:05, Daniel Fuchs wrote: Hi Patrick: DatagramSocket.java: typo 712  * If there is a security manager, and th esocket is not currently Otherwise looks good to me too! best re

Re: RFR[8230946]: Clarify security manager behaviour of a connected DatagramSocket and DatagramChannel

Hi Patrick: DatagramSocket.java: typo 712 * If there is a security manager, and th esocket is not currently Otherwise looks good to me too! best regards, -- daniel On 02/10/2019 10:49, Patrick Concannon wrote: Hi, I've updated the fix for JDK-8230946

Re: RFR[8230946]: Clarify security manager behaviour of a connected DatagramSocket and DatagramChannel

> On 2 Oct 2019, at 10:49, Patrick Concannon > wrote: > Hi, > > I've updated the fix for JDK-8230946 with the feedback received here and from > the CSR (JDK-8231305). The new webrev can be found below: > http://cr.openjdk.java.net/~pconcannon/8230946/webrevs/webrev.04/ > Thanks Patrick. Loo

Re: RFR[8230946]: Clarify security manager behaviour of a connected DatagramSocket and DatagramChannel

nnel.receive does not specify that it discards datagrams when denied by the SM. I think we will need to adjust the wording for the SecurityException. DatagramChannel::receive has the following @throws: * @throws  SecurityException *  If a security manager has been installed   

Re: RFR[8230946]: Clarify security manager behaviour of a connected DatagramSocket and DatagramChannel

need to adjust the wording for the SecurityException. DatagramChannel::receive has the following @throws: * @throws SecurityException * If a security manager has been installed * and it does not permit datagrams to be accepted * from the datagram&#

Re: RFR[8230946]: Clarify security manager behaviour of a connected DatagramSocket and DatagramChannel

On 30/09/2019 15:10, Patrick Concannon wrote: Hi Alan, A new issue has been created as requested, and can be found here: https://bugs.openjdk.java.net/browse/JDK-8231570 In JDK-8231570, I think Chris is concerned that a custom SM will observe, and may prevent, send/receive from binding where

Re: RFR[8230946]: Clarify security manager behaviour of a connected DatagramSocket and DatagramChannel

or is to drop the datagram. Separate issue but we should try to fix that while in the area. I also note that both DatagramSocket and DatagramChannel may have to bind on first usage which may involve a permission check that we should ensure all succeeds. Regarding the above, I can open this

Re: RFR[8230946]: Clarify security manager behaviour of a connected DatagramSocket and DatagramChannel

x27;s receive spec too. The specification is that a SecurityException is thrown but the implementation behavior is to drop the datagram. Separate issue but we should try to fix that while in the area. I also note that both DatagramSocket and DatagramChannel may have to bind on first usage which may in

Re: RFR[8230946]: Clarify security manager behaviour of a connected DatagramSocket and DatagramChannel

hat a SecurityException is thrown but the implementation behavior is to drop the datagram. Separate issue but we should try to fix that while in the area. I also note that both DatagramSocket and DatagramChannel may have to bind on first usage which may involve a permission check that we should ensur

Re: RFR[8230946]: Clarify security manager behaviour of a connected DatagramSocket and DatagramChannel

On 24/09/2019 16:01, Patrick Concannon wrote: Hi, Would it be possible to have both my fix JDK-8230946, and CSR JDK-8231305, reviewed? This fix and CSR addresses the javadocs for DatagramSocket::receive, DatagramChannel::connect and DatagramChannel::receive and aims at clarifying the

RFR[8230946]: Clarify security manager behaviour of a connected DatagramSocket and DatagramChannel

Hi, Would it be possible to have both my fix JDK-8230946, and CSR JDK-8231305, reviewed? This fix and CSR addresses the javadocs for DatagramSocket::receive, DatagramChannel::connect and DatagramChannel::receive and aims at clarifying the Security Manager behaviour on a connected

Re: [RFR] 8224645: Test java/nio/channels/DatagramChannel/BasicMulticastTests.java fails with NoSuchElementException

Pushed, thanks for the reviews. On Thu, Jun 6, 2019 at 4:23 AM Chris Hegarty wrote: > +1 from me too. > > Arthur, > > This test is failing quite frequently in our build and test system. If not > pushed by this time tomorrow, I will push it on your behalf. > > -Chris. > > > On 6 Jun 2019, at 12:1

Re: [RFR] 8224645: Test java/nio/channels/DatagramChannel/BasicMulticastTests.java fails with NoSuchElementException

+1 from me too. Arthur, This test is failing quite frequently in our build and test system. If not pushed by this time tomorrow, I will push it on your behalf. -Chris. > On 6 Jun 2019, at 12:13, Daniel Fuchs wrote: > > Hi Arthur, > > Looks good to me too. > I have run it through our test sys

Re: [RFR] 8224645: Test java/nio/channels/DatagramChannel/BasicMulticastTests.java fails with NoSuchElementException

Hi Arthur, Looks good to me too. I have run it through our test system and saw no issues. best regards, -- daniel On 04/06/2019 11:27, Alan Bateman wrote: On 03/06/2019 16:17, Arthur Eubanks wrote: I don't think it's a big difference either way, but changed it to System.out. Also ad

Re: [RFR] 8224645: Test java/nio/channels/DatagramChannel/BasicMulticastTests.java fails with NoSuchElementException

On 03/06/2019 16:17, Arthur Eubanks wrote: I don't think it's a big difference either way, but changed it to System.out. Also added some extra info to the "Exception Tests" log to show the addresses it's testing. Now it looks like: webrev.03 looks okay to me. -Alan

  1   2   >