[teststabilization] RFR: 8226756: Replace wildcard address with loopback or local host in tests - part 18

Hi, Would it be possible to have my fix for JDK-8226756 reviewed? This test is a part of the Network Stabilization Test Set: Replace wildcard address with loopback or local host in tests - part 18. Further information on fixes can be found here: https://bugs.openjdk.java.net/browse/JDK-8226756

Re: [teststabilization] RFR: 8226756: Replace wildcard address with loopback or local host in tests - part 18

w/protocol/http/NoCache.java:   51 .host(InetAddress.getLocalHost()) You could use:   51 .host(server.getAddress().getAddress()) here to be consistent with the following line. Otherwise looks good! cheers, -- daniel On 04/07/2019 15:07, Patrick Concannon wrote:

RFR: 8227721: NetworkInterfaceRetrievalTests.java should open the java.net package

Hi, Would it be possible to have my fix for JDK-8227721 reviewed? test/jdk/java/net/NetworkInterface/NetworkInterfaceRetrievalTests.java has been recently modified to perform a deep reflection ( setAccessible(true) ) on a non-public member java.net.NetworkInterface::isBoundInetAddress. Howeve

Re: RFR: 8227721: NetworkInterfaceRetrievalTests.java should open the java.net package

Oh OK, I didn't realise. Thanks for pointing this out, Alan! I've removed the 'othervm' tag, and added it to the new webrev below. http://cr.openjdk.java.net/~aefimov/pconcann/8227721/01/ Kind regards, Patrick On 18/07/2019 08:53, Alan Bateman wrote: On 17/07/2019 17:5

RFR: 8228970: AssertionError in ResponseSubscribers$HttpResponseInputStream

Hi, Would it be possible to have my fix for JDK-8228970 reviewed? The fix modifies the read(byte[], int, int) method from ResponseSubscribers$HttpResponseInputStream adding further checks for bad parameters. I've also added an additional test case that ensures that these checks are being met.

Re: RFR: 8228970: AssertionError in ResponseSubscribers$HttpResponseInputStream

Hi, Thanks for the feedback, Pavel. I'll make that switch now! Kind regards, Patrick On 06/08/2019 11:31, Pavel Rappo wrote: May I suggest using org.testng.Assert.assertThrows instead of hand-rolled try-catch constructs in the test? On 6 Aug 2019, at 11:12, Patrick Concannon wrote

Re: RFR: 8228970: AssertionError in ResponseSubscribers$HttpResponseInputStream

Hi, Please find a link to the updated webrev below: http://cr.openjdk.java.net/~dfuchs/pconcann/8228970/webrevs/webrev.3/ Kind regards, Patrick On 06/08/2019 12:08, Patrick Concannon wrote: Hi, Thanks for the feedback, Pavel. I'll make that switch now! Kind regards, Patrick On

Re: RFR: 8228970: AssertionError in ResponseSubscribers$HttpResponseInputStream

Will do. Thanks Chris Kind regards, Patrick On 07/08/2019 12:35, Chris Hegarty wrote: Patrick, On 07/08/2019 11:42, Daniel Fuchs wrote: On 07/08/2019 11:22, Patrick Concannon wrote: Hi, Please find a link to the updated webrev below: http://cr.openjdk.java.net/~dfuchs/pconcann/8228970

RFR [8203036]: com.sun.net.httpserver.HttpExchange should implement AutoCloseable

Hi, Would it be possible to have my fix, and corresponding CSR, for JDK-8203036 reviewed? This fix addresses the retrofitting of HttpExchange to implement AutoCloseable so that it can be used with try-with-resources statements. The CSR for the fix can be found here: https://bugs.openjdk.j

RFR[8229421]: The logic of java/net/ipv6tests/TcpTest.java is flawed

Hi, Would it be possible to have my fix for JDK-8229421 reviewed? This fix addresses an intermittent issue. Original test checked IPv4 connections couldn’t be made to server accepting connections over IPv6 only (and vice-versa). However, the test didn’t check for the false positive that can

Re: RFR[8229421]: The logic of java/net/ipv6tests/TcpTest.java is flawed

Apologies, the link to the bug ID in the original message was bad. Please see below for correct link to bug: https://bugs.openjdk.java.net/browse/JDK-8229421 On 14/08/2019 12:30, Patrick Concannon wrote: Hi, Would it be possible to have my fix for JDK-8229421 reviewed? This fix addresses

RFR[8229916]: Delete redundant test java/net/Socket/reset/Test.java

Hi, Would it be possible to have my fix for JDK-8229916 reviewed? The test file java/net/Socket/reset/Test.java was missing JTReg @test tag, and wasn't working. It has since been replaced with a more up to date test -- java/net/Socket/ConnectionReset.java -- making it redundant. This fix re

RFR 8078219: Verify lack of @test tag in files in java/net test directory

Hi, Would it be possible to have my fix for JDK-8078219 reviewed? Several tests in java.net were found to be missing their JTReg @test tags: 1. test/jdk/java/net/MulticastSocket/Reuse.java -- Test tag added. Test worked as expected 2. test/jdk/java/net/URLClassLoader/GetURLsTest.java -- Tes

Re: RFR 8078219: Verify lack of @test tag in files in java/net test directory

Hi, Thanks Alan for the suggestions. I've made those changes below: http://cr.openjdk.java.net/~aefimov/pconcann/8078219/01/ Kind regards, Patrick On 20/08/2019 15:44, Alan Bateman wrote: On 20/08/2019 15:27, Patrick Concannon wrote: Hi, Would it be possible to have my fix fo

Re: RFR 8078219: Verify lack of @test tag in files in java/net test directory

Ok, I will fix before pushing! On 21/08/2019 13:09, Alan Bateman wrote: y prefer "static final" over "final static".

RFR [8193596]: java/net/DatagramPacket/ReuseBuf.java failed due to timeout

Hi, Would it be possible to have my fix for JDK-8193596 reviewed? The test fails intermittently due to binding to wildcard addresses -- similar to those that have been fixed under the umbrella of JDK-8222938 . This fix changes the binding fro

RFR[8230132]: java/net/NetworkInterface/NetworkInterfaceRetrievalTests.java to skip Teredo Tunneling Pseudo-Interface

Hi, Would it be possible to have my fix for JDK-8230132 reviewed? java/net/NetworkInterface/NetworkInterfaceRetrievalTests.java was failing intermittently on Windows due to random addresses being returned from the virtual interface "Teredo Tunneling Pseudo-Interface". The fix checks for, and

RFR[8230159]: Add test to verify that com.sun.net.httpserver.BasicAuthenticator constructors throw expected exceptions

Hi, 

 Would it be possible to have my fix for JDK-8230159 reviewed? Test added to verify that com/sun/net/httpserver/BasicAuthenticator constructors throw expected exceptions. The com/sun/net/httpserver/BasicAuthenticator constructors specifies that NullPointerException will be thrown if r

Re: RFR[8230159]: Add test to verify that com.sun.net.httpserver.BasicAuthenticator constructors throw expected exceptions

to me, minor bit jtreg tag order in not correct ,  generally @run tag comes last. Thanks, Vyom - Original message - From: Daniel Fuchs Sent by: "net-dev" To: Patrick Concannon , OpenJDK Network Dev list Cc: Subject: [EXTERNAL] Re: RFR[8230159]: Add

Re: RFR[8230132]: java/net/NetworkInterface/NetworkInterfaceRetrievalTests.java to skip Teredo Tunneling Pseudo-Interface

ilize jdk.test.lib.Platform::isWindows from test library to check if the test is running on Windows platform. With Best Regards, Aleksei On 29/08/2019 16:01, Patrick Concannon wrote: Hi, Would it be possible to have my fix for JDK-8230132 reviewed? java/net/NetworkInterface/NetworkInterfaceRetrievalTests.jav

RFR[8217825]: Verify @AfterTest is used correctly in WebSocket tests

Hi, 

 Would it be possible to have my fix for JDK-8217825 - Verify @AfterTest is used correctly in WebSocket tests - reviewed? Following on from the discussion had here: https://mail.openjdk.java.net/pipermail/net-dev/2019-January/012141.html, I’ve refactored several websocket tests to exp

Re: RFR[8217825]: Verify @AfterTest is used correctly in WebSocket tests

I wonder if you should be using `try { } finally { }` to ensure that the websocket is closed too:    var websocket = .;    try { // send some messages etc...    } finally { websocket.abort();    } best regards, -- daniel On 13/09/2019 15:36, Patrick Concannon wrote: Hi, 

 Would it be p

Re: RFR[8217825]: Verify @AfterTest is used correctly in WebSocket tests

ep 2019, at 11:36, Daniel Fuchs wrote: Hi Patrick, Looks good to me! best regards, -- daniel On 20/09/2019 11:27, Patrick Concannon wrote: Hi Daniel, Thanks for the feedback. That's a good idea. I've made those changes and I've included them in the webrev below. http://cr.open

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 DatagramS

RFR[8222829]: DatagramSocket.setSoTimeout does not specify IAE when timeout is negative

Hi, Would it be possible to have both my fix JDK-8222829, and CSR JDK-8231401, reviewed? This fix and CSR address the javadoc for DatagramSocket::setSoTimeout, and make explicit that an IllegalArgumentException will be thrown when passed a negative timeout value. webrev: http://cr.openj

Re: RFR[8222829]: DatagramSocket.setSoTimeout does not specify IAE when timeout is negative

garty wrote: Patrick, On 25/09/2019 15:50, Patrick Concannon wrote: Hi, Would it be possible to have both my fix JDK-8222829, and CSR JDK-8231401, reviewed? This fix and CSR address the javadoc for DatagramSocket::setSoTimeout, and make explicit that an IllegalArgumentException will be t

Re: RFR[8222829]: DatagramSocket.setSoTimeout does not specify IAE when timeout is negative

Hi Alan, I've added a similar check for DatagramChannel socket adaptor as requested. You can find it in the webrev below. http://cr.openjdk.java.net/~pconcannon/8219446/webrevs/webrev.01/ Kind regards, Patrick On 26/09/2019 14:38, Alan Bateman wrote: On 26/09/2019 14:26, Pa

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

Hi Alan, Thanks for the review. On 24/09/2019 16:25, Alan Bateman wrote: The clarification to DatagramSocket.receive on how it behaves when there is a security manager and not connected may require some adjusting to DatagramChannel's receive spec too. The specification is that a SecurityEx

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

Hi Alan, A new issue has been created as requested, and can be found here: https://bugs.openjdk.java.net/browse/JDK-8231570 Kind regards, Patrick On 27/09/2019 16:49, Alan Bateman wrote: On 27/09/2019 16:07, Patrick Concannon wrote: Hi Alan, Thanks for the review. On 24/09/2019 16

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

concannon/8230946/webrevs/webrev.04/ Kind regards, Patrick On 30/09/2019 16:45, Chris Hegarty wrote: On 30/09/2019 15:27, Alan Bateman wrote: 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.ja

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

best regards, -- daniel On 02/10/2019 10:49, Patrick Concannon wrote: Hi, I've updated the fix for JDK-8230946 <https://bugs.openjdk.java.net/browse/JDK-8230946>with the feedback received here and from the CSR (JDK-8231305 <https://bugs.openjdk.java.net/browse/JDK-8231305>).

Re: RFR[8222829]: DatagramSocket.setSoTimeout does not specify IAE when timeout is negative

: On 26/09/2019 14:26, Patrick Concannon wrote: I've added the test case to test/jdk/java/net/DatagramSocket/DatagramTimeout.java as requested. You can find the new webrev here: http://cr.openjdk.java.net/~pconcannon/8222829/webrevs/webrev.01/ Looks good to me Patrick! best regards, -- daniel

RFR[8231719 ]: Correct contradictions in timeout range descriptions

Hi, Could someone please review my fix and CSR for JDK-8231719 'Correct contradictions in timeout range descriptions' ? The fix changes the wording of the API spec to remove the contradiction in the valid range for timeout values. webrev

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/8231570/webrevs/webr

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.openjdk.java.net/

RFR[8233989]: Create an IPv4 version of java/net/MulticastSocket/SetLoopbackMode.java

Hi, Could someone please review my fix for issue JDK-8233989 'Create an IPv4 version of java/net/MulticastSocket/SetLoopbackMode.java' ? This fix circumvents the issue by adding a new SetLoopbackModeIPv4 test that calls SetLoopbackMode in IPv4 only mode, and runs only if IPv4 is enabled.

RFR[8233860]: java/net/SocketOption/AfterClose.java test incorrectly handles IP_MULTICAST_IF

Hi, Could someone please review my fix for issue JDK-8233860 'java/net/SocketOption/AfterClose.java test incorrectly handles IP_MULTICAST_IF' ? The test, AfterClose.java, makes a call to setOption() after a socket has been closed to verify that a SocketException is thrown correctly. Howeve

Re: RFR[8233860]: java/net/SocketOption/AfterClose.java test incorrectly handles IP_MULTICAST_IF

Hi Alan, Thanks for your feedback. My mistake. I've changed that now in the webrev below. http://cr.openjdk.java.net/~pconcannon/8233860/webrevs/webrev.01/ Kind regards, Patrick On 13/11/2019 16:53, Alan Bateman wrote: On 13/11/2019 16:12, Patrick Concannon wrote: Hi, Could so

Re: RFR[8233860]: java/net/SocketOption/AfterClose.java test incorrectly handles IP_MULTICAST_IF

inor bit i will suggest you to use "List.of()" in place of"new ArrayList<>();". Thanks, Vyom ----- Original message - From: Patrick Concannon Sent by: "net-dev" To: Alan Bateman , OpenJDK Network Dev list Cc: Subject: [EXTERNA

RFR[8234103]: DatagramSocketImpl::socket is not needed

Hi, Could someone please review my fix for issue JDK-8234103 'DatagramSocketImpl::socket is not needed' ? DatagramSocketImpl has a socket field that links back to the DatagramSocket, which is only used to determine whether this DatagramSocket support Multicast or not. This fix removes the D

RFR[8233018]: Add a new test to verify that DatagramSocket is not interruptible

Hi, Could someone please review my fix for issue JDK-8233018 'Add a new test to verify that DatagramSocket is not interruptible'? This fix adds a test to check the interruptability of DatagramSocket, MulticastSocket and DatagramSocketAdaptor. bug: https://bugs.openjdk.java.net/browse/JDK-

Re: RFR[8234103]: DatagramSocketImpl::socket is not needed

wise looks good! best regards, --  daniel On 14/11/2019 11:58, Patrick Concannon wrote: Hi, Could someone please review my fix for issue JDK-8234103 'DatagramSocketImpl::socket is not needed' ? DatagramSocketImpl has a socket field that links back to the DatagramSocket, which is on

RFR[8234083]: DatagramSocket should report SO_BROADCAST as a supported option

Hi, Could someone please review my fix for issue JDK-8234083 'DatagramSocket should report SO_BROADCAST as a supported option'? DatagramSocket has setBroadcast/getBroadcast methods, but omits SO_BROADCAST as a supported option. This fix adds SO_BROADCAST as a valid option, and updates Optio

RFR[8233307]: MulticastSocket getOption(IP_MULTICAST_IF) returns interface when not set

Hi, Could someone please review my fix and CSR for issue JDK-8233307 'MulticastSocket getOption(IP_MULTICAST_IF) returns interface when not set'? The IP_MULTICAST_IF socket option is specified to have an initial value of null to mean that the interface has not been set. However, if Multicas

Re: RFR[8233307]: MulticastSocket getOption(IP_MULTICAST_IF) returns interface when not set

trick, On 27 Nov 2019, at 14:54, Patrick Concannon wrote: Hi, Could someone please review my fix and CSR for issue JDK-8233307 'MulticastSocket getOption(IP_MULTICAST_IF) returns interface when not set'? The IP_MULTICAST_IF socket option is specified to have an initial value of nul

RFR[8234148]: DatagramSocket.setOption/getOption/supportedOption should support multicast options

Hi, Could some please review my fix for issue JDK-8234148 'DatagramSocket.setOption/getOption/supportedOption should support multicast options'? DatagramSocket can be used to send multicast datagrams but it isn't possible to set multicast options on it. This fix adds multicast socket optio

RFR[8233191]: MulticastSocket joinGroup/leaveGroup do not specify their behavior when the outgoing interface has not been set

Hi, Could some please review my fix for issue JDK-8233191 'MulticastSocket joinGroup/leaveGroup do not specify their behavior when the outgoing interface has not been set'? This javadoc fix clarifies the behaviour of 2-arg joinGroup/leaveGroup methods when null is passed for the NetworkInte

Re: RFR[8233191]: MulticastSocket joinGroup/leaveGroup do not specify their behavior when the outgoing interface has not been set

Hi, Thanks for the feedback. I've made those changes now, and you can find them in the new webrev below. http://cr.openjdk.java.net/~pconcannon/8233191/webrevs/webrev.01/ Kind regards, Patrick On 05/12/2019 16:28, Daniel Fuchs wrote: On 05/12/2019 16:14, Alan Bateman wrote: bug: https:/

Re: RFR[8233191]: MulticastSocket joinGroup/leaveGroup do not specify their behavior when the outgoing interface has not been set

7:39, Alan Bateman wrote: On 05/12/2019 17:17, Patrick Concannon wrote: Hi, Thanks for the feedback. I've made those changes now, and you can find them in the new webrev below. http://cr.openjdk.java.net/~pconcannon/8233191/webrevs/webrev.01/ I should have been clearer, my comment wasn&#x

Re: RFR[8234148]: DatagramSocket.setOption/getOption/supportedOption should support multicast options

?. Thanks, Vyom - Original message - From: Alan Bateman Sent by: "net-dev" To: Daniel Fuchs , Patrick Concannon , OpenJDK Network Dev list Cc: Subject: [EXTERNAL] Re: RFR[8234148]: DatagramSocket.setOption/getOption/supportedOption should supp

Re: RFR[8234148]: DatagramSocket.setOption/getOption/supportedOption should support multicast options

emove these two lines as SO_REUSEPORT is obviously not supported as per line 215. best regards, -- daniel On 05/12/2019 15:41, Patrick Concannon wrote: Hi, Could some please review my fix for issue JDK-8234148 'DatagramSocket.setOption/getOption/supportedOption should support multica

RFR[8235783]: DatagramSocket::disconnect should allow an implementation to throw UncheckedIOException

Hi, Could someone please review my fix and CSR for issue JDK-8235783 'DatagramSocket::disconnect should allow an implementation to throw UncheckedIOException'? DatagramChannel's connect and disconnect methods throw an IOException while DatagramSocket's corresponding methods do not. The propo

Re: RFR[8235783]: DatagramSocket::disconnect should allow an implementation to throw UncheckedIOException

Hi Alan, Thanks for the feedback. I've incorporated your comments into the webrev below. http://cr.openjdk.java.net/~pconcannon/8235783/webrevs/webrev.01/ Kind regards, Patrick On 18/12/2019 10:01, Alan Bateman wrote: On 17/12/2019 14:35, Patrick Concannon wrote: Hi, Could someone p

Re: RFR[8235783]: DatagramSocket::disconnect should allow an implementation to throw UncheckedIOException

Hi Chris, Well spotted. I've made those changes and updated the webrev. http://cr.openjdk.java.net/~pconcannon/8235783/webrevs/webrev.02/ Kind regards, Patrick On 10/01/2020 16:17, Chris Hegarty wrote: Patrick. On 10 Jan 2020, at 15:26, Patrick Concannon wrote: Hi Alan, Thank

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 DatagramSocketAdaptor are not consist

@since tag missing from DatagramSocket and MulticastSocket methods

Hi, Could someone please review my fix for JDK-8237075 '@since tag missing from DatagramSocket and MulticastSocket methods' ? This trivial fix adds in the missing @since tags for methods listed below. These methods were originally added in JDK 1.2. java/net/DatagramSocket: > public void co

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

 694  * is not set.  this line needs to be removed. Otherwise this looks good to me. A release note might get requested by the CSR lead. best regards, -- daniel On 13/01/2020 16:30, Patrick Concannon wrote: Hi, Could someone please review my fix and CSR for issue JDK-8236105 'Be

RFR[8237571]: java/net/DatagramSocket/SendCheck.java is failing on Solaris

Hi, Could someone please review my fix for issue JDK-8237571 'java/net/DatagramSocket/SendCheck.java is failing on Solaris' ? A test case in java/net/DatagramSocket/SendCheck.java is failing Solaris. This bug was highlighted by issue JDK-8236852

RFR[7021373]: DatagramPacket exception conditions are not clear

Hi, Could someone please review my fix and CSR for issue JDK-7021373 'DatagramPacket exception conditions are not clear' ? This fix updates the spec concerning the exceptions thrown by the constructors of the DatagramPacket class, and several methods therein. bug: https://bugs.openjdk.java

Re: RFR[7021373]: DatagramPacket exception conditions are not clear

Hi, Thanks everyone for the feedback. Chris, I've incorporated the changes you asked for, and they can be found in the updated webrev here: http://cr.openjdk.java.net/~pconcannon/7021373/webrevs/webrev.01/ I’ve taken the @throws IAE from DatagramPacket::getSocketAddress, and logged it as a

RFR[8237480]: Add micros for DatagramSocket send/receive

Hi, Could someone please review my webrev for JDK-8237480 'Add micros for DatagramSocket send/receive' ? This change adds some benchmarks for the DatagramSocket::send and DatagramSocket::receive methods. bug: https://bugs.openjdk.java.net/browse/JDK-8237480 webrev: http://cr.openjdk.java

Re: RFR[8237480]: Add micros for DatagramSocket send/receive

the size parameter (3-5 values seem reasonable). /Claes On 2020-02-12 16:04, Patrick Concannon wrote: Hi, Could someone please review my webrev for JDK-8237480 'Add micros for DatagramSocket send/receive' ? This change adds some benchmarks for the DatagramSocket::send and Datagr

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-8234812 webrev: http://cr.openjdk.java.ne

Re: RFR[8237480]: Add micros for DatagramSocket send/receive

ome of the 9 values for the size parameter (3-5 values seem reasonable). /Claes On 2020-02-12 16:04, Patrick Concannon wrote: Hi, Could someone please review my webrev for JDK-8237480 'Add micros for DatagramSocket send/receive' ? This change adds some benchmarks for the DatagramSocket::

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

RFR[8239355]: '(dc) Initial value of SO_SNDBUF should allow sending large datagrams (macOS)'

Hi, Could someone please review my fix for JDK-8239355 '(dc) Initial value of SO_SNDBUF should allow sending large datagrams (macOS)' ? By default, macOS imposes a size of 9216on Datagrams which limits applications that don't set the SO_SNDBUF option - legacy DatagramSocket sets the value to

Re: RFR[8239355]: '(dc) Initial value of SO_SNDBUF should allow sending large datagrams (macOS)'

trick On 09/03/2020 20:03, Alan Bateman wrote: On 09/03/2020 18:08, Daniel Fuchs wrote: Hi Alan, On 09/03/2020 17:01, Alan Bateman wrote: On 09/03/2020 12:39, Patrick Concannon wrote: bug: https://bugs.openjdk.java.net/browse/JDK-8239355 webrev: http://cr.openjdk.java.net/~pconcannon/82

Re: RFR[8239355]: '(dc) Initial value of SO_SNDBUF should allow sending large datagrams (macOS)'

Hi, I've included those additional changes, and they can be found in the new webrev below. http://cr.openjdk.java.net/~pconcannon/8239355/webrevs/webrev.03/ Kind regards, Patrick On 11/03/2020 12:27, Daniel Fuchs wrote: Hi Alan, On 11/03/2020 12:08, Alan Bateman wrote: Do we really? I a

Re: RFR[8239355]: '(dc) Initial value of SO_SNDBUF should allow sending large datagrams (macOS)'

Regarding the test to check that large datagrams are sent and received correctly across a network:  I've created a new issue for it and included the link below. https://bugs.openjdk.java.net/browse/JDK-8240901 Kind regards, Patrick On 11/03/2020 16:54, Patrick Concannon wrote: Hi,

RFR[8241072]: 'Reimplement Legacy DatagramSocket API'

This is a request for review for the implementation changes for JEP 373: 'Reimplement Legacy DatagramSocket API' [1]. A CSR has also been created [2]. The implementation of JEP 373 can be viewed on the JDK-8230211-branch in the sandbox [3]. A link to the webrev with the cumulated changes is

Re: RFR[8241072]: 'Reimplement Legacy DatagramSocket API'

teman wrote: On 23/03/2020 16:37, Patrick Concannon wrote: This is a request for review for the implementation changes for JEP 373: 'Reimplement Legacy DatagramSocket API' [1]. A CSR has also been created [2]. The implementation of JEP 373 can be viewed on the JDK-8230211-branch in

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 when connecting. DatagramChan

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: RFR[8240533]: 'Inconsistent Exceptions are thrown by DatagramSocket and DatagramChannel when sending a DatagramPacket to port 0.'

there in other tests - I think a single permission:     { perms.add(new SocketPermission("*:0")); } would be more robust as it would take care of both IPv6 and IPv4 in one go. We should strive to avoid to hard-code 127.0.0.1 and 0.0.0.0 in tests. best regards, -- daniel On 03/04/2020 1

Re: RFR[8241072]: 'Reimplement Legacy DatagramSocket API'

Hi, Alan - I've gone through your comments and refactored the code accordingly. I spoke with Daniel about the SendBufCheck test, and he wants to keep this in the JEP as it allows to compare the behavior of all the different implementations in one place. Chris - Thanks for opening issue JDK-8

RFR[8237890]: 'DatagramPacket::getSocketAddress doesn't specify what happens if address or port are not set'

Hi, Could someone please review my webrev and CSR for JDK-8237890 'DatagramPacket::getSocketAddress doesn't specify what happens if address or port are not set' ? DatagramPacket::getSocketAddress is misleading in that it can throw an IllegalArgumentException even though it doesn't take any a

Re: RFR[8237890]: 'DatagramPacket::getSocketAddress doesn't specify what happens if address or port are not set'

. webrev: http://cr.openjdk.java.net/~pconcannon/8237890/webrevs/webrev.01/ Kind regards, Patrick On 10/04/2020 13:28, Alan Bateman wrote: On 10/04/2020 11:16, Patrick Concannon wrote: Hi, Could someone please review my webrev and CSR for JDK-8237890 'DatagramPacket::getSocketAddress doesn'

Re: RFR[8241072]: 'Reimplement Legacy DatagramSocket API'

Patrick On 12/04/2020 16:51, Alan Bateman wrote: On 09/04/2020 12:26, Patrick Concannon wrote: Hi, Alan - I've gone through your comments and refactored the code accordingly. Just a few minor comments on the implementation changes. DatagramSocket.java - this version of the webrev ha

Re: RFR[8237890]: 'DatagramPacket::getSocketAddress doesn't specify what happens if address or port are not set'

Hi Chris, Thanks for that. I've added the new testcases as requested, and you can find them in the new webrev below. http://cr.openjdk.java.net/~pconcannon/8237890/webrevs/webrev.02/ Kind regards, Patrick On 15/04/2020 16:54, Chris Hegarty wrote: On 15 Apr 2020, at 16:40, Pa

RFR[8243408]: 'Inconsistent Exceptions are thrown by MulticastSocket when sending a DatagramPacket to port 0'

Hi, Could someone please review my fix for JDK-8243408 'Inconsistent Exceptions are thrown by MulticastSocket when sending a DatagramPacket to port 0'? Currently, MulticastSocket.send(DatagramPacket, byte) throws an IOException when sending to port 0 on Unix and macOS, but doesn’t throw on

RFR[8243488]: 'Add tests for set/get SendBufferSize and getReceiveBufferSize in DatagramSocket'

Hi, Could someone please review my fix for JDK-8243488 'Add tests for set/get SendBufferSize and getReceiveBufferSize in DatagramSocket'? This fix adds tests for the methods: setSendBufferSize(int), getSendBufferSize(), and getReceieveBufferSize() in the DatagramSocket class, and is geared t

Re: RFR[8243488]: 'Add tests for set/get SendBufferSize and getReceiveBufferSize in DatagramSocket'

Hi Alan, Yeah, sounds good. I’ve added that test case as requested, and you can find it in the updated webrev below. http://cr.openjdk.java.net/~pconcannon/8243488/webrevs/webrev.01/ Kind regards, Patrick On 24/04/2020 09:59, Alan Bateman wrote: On 23/04/2020 16:46, Patrick Concannon

RFR[8243507]: 'DatagramSocket constructors don’t always specify what happens when passed invalid parameters'

Hi, Could someone please review my fix for JDK-8243507 'DatagramSocket constructors don’t always specify what happens when passed invalid parameters'? Currently, the DatagramSocket constructor `DatagramSocket(SocketAddress bindaddr)` doesn't specify what happens if passed a SocketAddress su

Re: RFR[8243507]: 'DatagramSocket constructors don’t always specify what happens when passed invalid parameters'

egards Mark *From:* net-dev on behalf of Daniel Fuchs *Sent:* Tuesday 28 April 2020 15:32 *To:* Patrick Concannon ; OpenJDK Network Dev list *Subject:* Re: RFR[8243507]: 'DatagramSocket constructors don’t always specify what happens when passed invalid

Re: RFR[8243488]: 'Add tests for set/get SendBufferSize and getReceiveBufferSize in DatagramSocket'

/webrev.02/ Kind regards, Patrick On 25/04/2020 15:53, Alan Bateman wrote: On 24/04/2020 21:00, Patrick Concannon wrote: Hi Alan, Yeah, sounds good. I’ve added that test case as requested, and you can find it in the updated webrev below. http://cr.openjdk.java.net/~pconcannon/8243488/webrevs

Re: RFR[8243488]: 'Add tests for set/get SendBufferSize and getReceiveBufferSize in DatagramSocket'

Hi, I've refactored the test to use the name 'DatagramSocketSupplier' instead of 'DSF' for the @FunctionalInterface, and used the supplier method as Daniel suggested. The updates can be found in the patch below. http://cr.openjdk.java.net/~pconcannon/8243488/webrevs/webrev.03/ Kind regards

Re: RFR[8241072]: 'Reimplement Legacy DatagramSocket API'

tps://bugs.openjdk.java.net/browse/JDK-8243488>). Please find the updated webrev below: http://cr.openjdk.java.net/~pconcannon/8241072/webrevs/webrev.05/ Kind regards, Patrick On 17/04/2020 10:35, Alan Bateman wrote: On 15/04/2020 20:22, Patrick Concannon wrote: : WRT the PDSI issue, I've creat

Re: RFR[8241072]: 'Reimplement Legacy DatagramSocket API'

Hi Alan, Thanks for your review. Sounds good, will remove the file before pushing and use as test for JDK-8242885 instead. Kind regards, Patrick On 07/05/2020 10:38, Daniel Fuchs wrote: Hi Alan, On 07/05/2020 07:59, Alan Bateman wrote: I'd prefer to see JDK-8242885 fixed and SetGetSendB

RFR[8242885]: 'PlainDatagramSocketImpl doesn’t allow for the sending of IPv6 datagrams on macOS with sizes between 65508-65527 bytes'

Hi, Could someone please review my fix for JDK-8242885 'PlainDatagramSocketImpl doesn’t allow for the sending of IPv6 datagrams on macOS with sizes between 65508-65527 bytes'? This fix changes the current max size for IPv6 datagrams on macOS from it's current size of 65507, which is the IPv4

Re: RFR 15 8243099: SO_INCOMING_NAPI_ID support

Hi Vladamir, Just a few observations with your test, ExtOptionNAPITest: I don't think the static class TestThread is needed for what you're trying to check and I think you can remove it. Also, I think using testNG assertions rather than throwing RunTimeExceptions might be better here, for exam

Re: RFR 15 8243099: SO_INCOMING_NAPI_ID support

: Patrick Concannon Sent: Monday, May 11, 2020 11:11 AM To: Ivanov, Vladimir A ; Alan Bateman ; OpenJDK Network Dev list Subject: Re: RFR 15 8243099: SO_INCOMING_NAPI_ID support Hi Vladamir, Just a few observations with your test, ExtOptionNAPITest: I don't think the static class TestThre

Re: [JBS] {Updated} (JDK-8245517) java/net/SocketOption/AfterClose.java fails with Invalid value 'READ_ONLY'

Hi Vladimir, The test AfterClose.java was added to ProblemList.txt after it was seen to be failing[1]. You'll need to remove it from the list along with your proposed fix. [1] https://bugs.openjdk.java.net/browse/JDK-8245518 Kind regards, Patrick On 21/05/2020 20:31, Daniel Fuchs wrote:

RFR[8244582]: 'Remove terminally deprecated Solaris-specific SO_FLOW_SLA socket option'

Hi, Could someone please review my webrev and CSR for JDK-8244582 'Remove terminally deprecated Solaris-specific SO_FLOW_SLA socket option'? This patch removes `ExtendedSocketOptions. SO_FLOW_SLA`, `SocketFlow` and `SocketFlow.Status` which were terminally deprecated in JDK 14 in preparation

Re: RFR[8244582]: 'Remove terminally deprecated Solaris-specific SO_FLOW_SLA socket option'

Kind regards, Patrick > On 28 May 2020, at 04:18, Vyom Tiwari wrote: > > Hi Patrick, > > Changes looks good to me. > > Thanks, > Vyom > > On Wed, May 27, 2020 at 9:12 PM Patrick Concannon > mailto:patrick.concan...@oracle.com>> wrote: > Hi, >

RFR[8246132]: 'AsynchronousSocketChannelNAPITest failing with a NotYetConnectedException'

Hi, Could someone please review my patch for JDK-8246132 - 'AsynchronousSocketChannelNAPITest failing with a NotYetConnectedException' ? AsynchronousSocketChannelNAPITest sometimes fails with a NotYetConnectedException while trying to read data after connecting. This is fix changes the connect

RFR[8243999]: ’DatagramSocket and MulticastSocket constructors don't specify how a null InetAddress is handled'

Hi, Could someone please review my patch and CSR for JDK-8243999 - ’DatagramSocket and MulticastSocket constructors don't specify how a null InetAddress is handled’? Currently, several constructors from DatagramSocket and MulticastSocket don't specify that the socket will be bound to the wildc

Re: RFR[8246132]: 'AsynchronousSocketChannelNAPITest failing with a NotYetConnectedException'

Hi Alan, That’s much more concise. Thanks for the tip! I’ve incorporated it into the updated webrev below. http://cr.openjdk.java.net/~pconcannon/8246132/webrevs/webrev.01/ Kind regards, Patrick > On 5 Jun 2020, at 06:33, Ala

Re: RFR[8243999]: ’DatagramSocket and MulticastSocket constructors don't specify how a null InetAddress is handled'

rgumentException if port is href="DatagramSocket.html#PortRange"> > 196 *out of range. > > Could you please make the change and regenerate the doc and double > check that the link in the generated doc is working? > > best regards, > > -- daniel

RFR[8245828]: 'Remove unnecessary NetworkPermission checks from jdk/net/ExtendedSocketOptions.java’

Hi, Could someone please review my fix for JDK-8245828 - ‘Remove unnecessary NetworkPermission checks from jdk/net/ExtendedSocketOptions.java’ ? With the removal of socket option SO_FLOW_SLA the NetworkPermission checks in jdk/net/ExtendedSocketOptions are no longer required. This fix removes t

  1   2   3   >