From michael.x.mcmahon at oracle.com Tue May 3 11:44:40 2016 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 3 May 2016 12:44:40 +0100 Subject: RFR: 8155928: Remove hardcoded port numbers from httpclient/Security.java test Message-ID: <57288F28.2000108@oracle.com> Some tests with hardcoded port numbers were included in the initial http tests. The fix uses a driver to allocate a free port and pass it into the existing security test through a system property. http://cr.openjdk.java.net/~michaelm/8155928/webrev.1/index.html Thanks, Michael From Roger.Riggs at Oracle.com Tue May 3 14:47:19 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 3 May 2016 10:47:19 -0400 Subject: RFR: 8155928: Remove hardcoded port numbers from httpclient/Security.java test In-Reply-To: <57288F28.2000108@oracle.com> References: <57288F28.2000108@oracle.com> Message-ID: <89a44b75-7b8a-2cb7-da37-2c547b9aa987@Oracle.com> Hi Michael, test/java/net/httpclient/security/15.policy: line 15: - Should this policy file include the substitution for the ${port.number}? Otherwise, it still looks like it has a fixed port #. Roger On 5/3/2016 7:44 AM, Michael McMahon wrote: > Some tests with hardcoded port numbers were included in the initial > http tests. > > The fix uses a driver to allocate a free port and pass it into the > existing > security test through a system property. > > http://cr.openjdk.java.net/~michaelm/8155928/webrev.1/index.html > > Thanks, > Michael From pavel.rappo at oracle.com Tue May 3 15:23:52 2016 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Tue, 3 May 2016 16:23:52 +0100 Subject: RFR JDK-8087113: Websocket API and implementation In-Reply-To: References: Message-ID: Hello, Here's an updated webrev with the latest implementation: http://cr.openjdk.java.net/~prappo/8087113/webrev.04/ If you're going to review it, please be advised that there is a number of known API and implementation issues yet to be resolved [1]. More API tests will be provided in the next couple of months. All applicable tests (1.1.1-10.1.1, 305 in total) from Autobahn Testsuite [2] are green. Thanks, -Pavel -------------------------------------------------------------------------------- [1] https://bugs.openjdk.java.net/browse/JDK-8155621 [2] http://autobahn.ws/testsuite/ > On 25 Mar 2016, at 16:21, Pavel Rappo wrote: > > Hi, > > Could you please review my change for JDK-8087113 > > http://cr.openjdk.java.net/~prappo/8087113/webrev.03/ > > This webrev contains initial implementation and basic tests for WebSocket API. > Specification conformance & interoperability testing has been performed with > Autobahn Testsuite [1]. As for API tests, I will provide more of them later. > > Thanks, > -Pavel > > -------------------------------------------------------------------------------- > [1] http://autobahn.ws/testsuite/ > From michael.x.mcmahon at oracle.com Wed May 4 16:06:28 2016 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 4 May 2016 17:06:28 +0100 Subject: RFR: 8155928: Remove hardcoded port numbers from httpclient/Security.java test In-Reply-To: <89a44b75-7b8a-2cb7-da37-2c547b9aa987@Oracle.com> References: <57288F28.2000108@oracle.com> <89a44b75-7b8a-2cb7-da37-2c547b9aa987@Oracle.com> Message-ID: <572A1E04.8040906@oracle.com> Hi Roger, Thanks for the review. That permission is not actually required for the test. But, it did make me look closer at it, and I realised that permission checking of the request URI port number was not being tested. So, that led me down a couple of rat holes which is why I haven't replied till now. So, I have updated the webrev at: http://cr.openjdk.java.net/~michaelm/8155928/webrev.2/ to remove the redundant permission check and also the following changes 1) There was a bug in the permission check where the host part of the URI was checked, but should have been the entire authority field. (Utils.java) 2) Add explicit test for a request URI and a real (randomly chosen) port number (test 1 in Security.java) 3) Fixed another strange issue in the Security test which causes failures if the jtreg work directory is not empty prior to running the test. (change in Security.moveFile) Thanks, Michael On 03/05/16 15:47, Roger Riggs wrote: > Hi Michael, > > test/java/net/httpclient/security/15.policy: line 15: > > - Should this policy file include the substitution for the > ${port.number}? > > Otherwise, it still looks like it has a fixed port #. > > Roger > > > On 5/3/2016 7:44 AM, Michael McMahon wrote: >> Some tests with hardcoded port numbers were included in the initial >> http tests. >> >> The fix uses a driver to allocate a free port and pass it into the >> existing >> security test through a system property. >> >> http://cr.openjdk.java.net/~michaelm/8155928/webrev.1/index.html >> >> Thanks, >> Michael > From Roger.Riggs at Oracle.com Wed May 4 17:23:32 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 4 May 2016 13:23:32 -0400 Subject: RFR: 8155928: Remove hardcoded port numbers from httpclient/Security.java test In-Reply-To: <572A1E04.8040906@oracle.com> References: <57288F28.2000108@oracle.com> <89a44b75-7b8a-2cb7-da37-2c547b9aa987@Oracle.com> <572A1E04.8040906@oracle.com> Message-ID: <4e9ce2a3-14da-c179-2e7c-2a23d771818a@Oracle.com> Hi Michael, Looks good, Roger p.s. btw, the webrev diffs for 'Wdiffs' don't show anything. On 5/4/2016 12:06 PM, Michael McMahon wrote: > Hi Roger, > > Thanks for the review. That permission is not actually required for the > test. But, it did make me look closer at it, and I realised that > permission > checking of the request URI port number was not being tested. So, that > led me > down a couple of rat holes which is why I haven't replied till now. > > So, I have updated the webrev at: > > http://cr.openjdk.java.net/~michaelm/8155928/webrev.2/ > > to remove the redundant permission check and also the following changes > > 1) There was a bug in the permission check where the host part of the URI > was checked, but should have been the entire authority field. > (Utils.java) > > 2) Add explicit test for a request URI and a real (randomly chosen) > port number > (test 1 in Security.java) > > 3) Fixed another strange issue in the Security test which causes > failures if the jtreg > work directory is not empty prior to running the test. (change in > Security.moveFile) > > Thanks, > Michael > > On 03/05/16 15:47, Roger Riggs wrote: >> Hi Michael, >> >> test/java/net/httpclient/security/15.policy: line 15: >> >> - Should this policy file include the substitution for the >> ${port.number}? >> >> Otherwise, it still looks like it has a fixed port #. >> >> Roger >> >> >> On 5/3/2016 7:44 AM, Michael McMahon wrote: >>> Some tests with hardcoded port numbers were included in the initial >>> http tests. >>> >>> The fix uses a driver to allocate a free port and pass it into the >>> existing >>> security test through a system property. >>> >>> http://cr.openjdk.java.net/~michaelm/8155928/webrev.1/index.html >>> >>> Thanks, >>> Michael >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Wed May 4 18:12:01 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 4 May 2016 19:12:01 +0100 Subject: RFR: 8155928: Remove hardcoded port numbers from httpclient/Security.java test In-Reply-To: <572A1E04.8040906@oracle.com> References: <57288F28.2000108@oracle.com> <89a44b75-7b8a-2cb7-da37-2c547b9aa987@Oracle.com> <572A1E04.8040906@oracle.com> Message-ID: Michael, getFreePort follows a failed pattern. There is no guarantee that the port will be ?free? when you actually require it. It will only reduce the likelihood of failure. Is there any way that the actual tests needing the port can create it themselves ( i understand that this will be more work, and possibly require some refactoring ). -Chris. On 4 May 2016, at 17:06, Michael McMahon wrote: > Hi Roger, > > Thanks for the review. That permission is not actually required for the > test. But, it did make me look closer at it, and I realised that permission > checking of the request URI port number was not being tested. So, that led me > down a couple of rat holes which is why I haven't replied till now. > > So, I have updated the webrev at: > > http://cr.openjdk.java.net/~michaelm/8155928/webrev.2/ > > to remove the redundant permission check and also the following changes > > 1) There was a bug in the permission check where the host part of the URI > was checked, but should have been the entire authority field. (Utils.java) > > 2) Add explicit test for a request URI and a real (randomly chosen) port number > (test 1 in Security.java) > > 3) Fixed another strange issue in the Security test which causes failures if the jtreg > work directory is not empty prior to running the test. (change in Security.moveFile) > > Thanks, > Michael > > On 03/05/16 15:47, Roger Riggs wrote: >> Hi Michael, >> >> test/java/net/httpclient/security/15.policy: line 15: >> >> - Should this policy file include the substitution for the ${port.number}? >> >> Otherwise, it still looks like it has a fixed port #. >> >> Roger >> >> >> On 5/3/2016 7:44 AM, Michael McMahon wrote: >>> Some tests with hardcoded port numbers were included in the initial http tests. >>> >>> The fix uses a driver to allocate a free port and pass it into the existing >>> security test through a system property. >>> >>> http://cr.openjdk.java.net/~michaelm/8155928/webrev.1/index.html >>> >>> Thanks, >>> Michael >> > From michael.x.mcmahon at oracle.com Wed May 4 20:52:11 2016 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 4 May 2016 21:52:11 +0100 Subject: RFR: 8155928: Remove hardcoded port numbers from httpclient/Security.java test In-Reply-To: References: <57288F28.2000108@oracle.com> <89a44b75-7b8a-2cb7-da37-2c547b9aa987@Oracle.com> <572A1E04.8040906@oracle.com> Message-ID: <572A60FB.9090107@oracle.com> Hi Chris, The problem is that the port number needs to be allocated outside the test VM because it needs to be specified as a system property given to the test VM. This system property is then evaluated in the policy file to give permission to that port. I can't think of an easy way to close the window completely as the http server creates its own server sockets and there would be no way to guarantee that any particular port is free at that moment. Maybe, one possibility is to catch the BindException, and return a specific error code from the child process which forces a retry? - Michael On 04/05/16 19:12, Chris Hegarty wrote: > Michael, > > getFreePort follows a failed pattern. There is no guarantee that the port will > be ?free? when you actually require it. It will only reduce the likelihood of > failure. Is there any way that the actual tests needing the port can > create it themselves ( i understand that this will be more work, and possibly > require some refactoring ). > > -Chris. > > > On 4 May 2016, at 17:06, Michael McMahon wrote: > >> Hi Roger, >> >> Thanks for the review. That permission is not actually required for the >> test. But, it did make me look closer at it, and I realised that permission >> checking of the request URI port number was not being tested. So, that led me >> down a couple of rat holes which is why I haven't replied till now. >> >> So, I have updated the webrev at: >> >> http://cr.openjdk.java.net/~michaelm/8155928/webrev.2/ >> >> to remove the redundant permission check and also the following changes >> >> 1) There was a bug in the permission check where the host part of the URI >> was checked, but should have been the entire authority field. (Utils.java) >> >> 2) Add explicit test for a request URI and a real (randomly chosen) port number >> (test 1 in Security.java) >> >> 3) Fixed another strange issue in the Security test which causes failures if the jtreg >> work directory is not empty prior to running the test. (change in Security.moveFile) >> >> Thanks, >> Michael >> >> On 03/05/16 15:47, Roger Riggs wrote: >>> Hi Michael, >>> >>> test/java/net/httpclient/security/15.policy: line 15: >>> >>> - Should this policy file include the substitution for the ${port.number}? >>> >>> Otherwise, it still looks like it has a fixed port #. >>> >>> Roger >>> >>> >>> On 5/3/2016 7:44 AM, Michael McMahon wrote: >>>> Some tests with hardcoded port numbers were included in the initial http tests. >>>> >>>> The fix uses a driver to allocate a free port and pass it into the existing >>>> security test through a system property. >>>> >>>> http://cr.openjdk.java.net/~michaelm/8155928/webrev.1/index.html >>>> >>>> Thanks, >>>> Michael From michael.x.mcmahon at oracle.com Wed May 4 22:59:00 2016 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 4 May 2016 23:59:00 +0100 Subject: RFR: 8155928: Remove hardcoded port numbers from httpclient/Security.java test In-Reply-To: References: <57288F28.2000108@oracle.com> <89a44b75-7b8a-2cb7-da37-2c547b9aa987@Oracle.com> <572A1E04.8040906@oracle.com> Message-ID: <572A7EB4.3000402@oracle.com> I've just updated the webrev at http://cr.openjdk.java.net/~michaelm/8155928/webrev.3 to retry the tests in the unlikely event of a BindException - Michael On 04/05/16 19:12, Chris Hegarty wrote: > Michael, > > getFreePort follows a failed pattern. There is no guarantee that the port will > be ?free? when you actually require it. It will only reduce the likelihood of > failure. Is there any way that the actual tests needing the port can > create it themselves ( i understand that this will be more work, and possibly > require some refactoring ). > > -Chris. > > > On 4 May 2016, at 17:06, Michael McMahon wrote: > >> Hi Roger, >> >> Thanks for the review. That permission is not actually required for the >> test. But, it did make me look closer at it, and I realised that permission >> checking of the request URI port number was not being tested. So, that led me >> down a couple of rat holes which is why I haven't replied till now. >> >> So, I have updated the webrev at: >> >> http://cr.openjdk.java.net/~michaelm/8155928/webrev.2/ >> >> to remove the redundant permission check and also the following changes >> >> 1) There was a bug in the permission check where the host part of the URI >> was checked, but should have been the entire authority field. (Utils.java) >> >> 2) Add explicit test for a request URI and a real (randomly chosen) port number >> (test 1 in Security.java) >> >> 3) Fixed another strange issue in the Security test which causes failures if the jtreg >> work directory is not empty prior to running the test. (change in Security.moveFile) >> >> Thanks, >> Michael >> >> On 03/05/16 15:47, Roger Riggs wrote: >>> Hi Michael, >>> >>> test/java/net/httpclient/security/15.policy: line 15: >>> >>> - Should this policy file include the substitution for the ${port.number}? >>> >>> Otherwise, it still looks like it has a fixed port #. >>> >>> Roger >>> >>> >>> On 5/3/2016 7:44 AM, Michael McMahon wrote: >>>> Some tests with hardcoded port numbers were included in the initial http tests. >>>> >>>> The fix uses a driver to allocate a free port and pass it into the existing >>>> security test through a system property. >>>> >>>> http://cr.openjdk.java.net/~michaelm/8155928/webrev.1/index.html >>>> >>>> Thanks, >>>> Michael From jitsni at gmail.com Wed May 4 23:20:00 2016 From: jitsni at gmail.com (Jitendra Kotamraju) Date: Wed, 4 May 2016 16:20:00 -0700 Subject: RFR JDK-8087113: Websocket API and implementation In-Reply-To: References: Message-ID: * I see that there is an issue for autoponging. May be this falls under it. The default impl of onPing() doesn't send PONG for *every* received PING. Since it is against the protocol semantics, it forces all applications to override the default onPing() impl. Is that right ? It seems to me that the basic issue here is that API allows only one outstanding send operation. That is also limiting for applications as applications need to do more work. * Since API allows these callback methods may be called by different threads, it is application responsibility to manage memory visibility and thread safety etc, right ? On Tue, May 3, 2016 at 8:23 AM, Pavel Rappo wrote: > > Hello, > > Here's an updated webrev with the latest implementation: > > http://cr.openjdk.java.net/~prappo/8087113/webrev.04/ > > If you're going to review it, please be advised that there is a number of > known > API and implementation issues yet to be resolved [1]. More API tests will > be > provided in the next couple of months. > > All applicable tests (1.1.1-10.1.1, 305 in total) from Autobahn Testsuite > [2] > are green. > > Thanks, > -Pavel > > > -------------------------------------------------------------------------------- > [1] https://bugs.openjdk.java.net/browse/JDK-8155621 > [2] http://autobahn.ws/testsuite/ > > > On 25 Mar 2016, at 16:21, Pavel Rappo wrote: > > > > Hi, > > > > Could you please review my change for JDK-8087113 > > > > http://cr.openjdk.java.net/~prappo/8087113/webrev.03/ > > > > This webrev contains initial implementation and basic tests for > WebSocket API. > > Specification conformance & interoperability testing has been performed > with > > Autobahn Testsuite [1]. As for API tests, I will provide more of them > later. > > > > Thanks, > > -Pavel > > > > > -------------------------------------------------------------------------------- > > [1] http://autobahn.ws/testsuite/ > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Thu May 5 10:13:53 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 5 May 2016 11:13:53 +0100 Subject: RFR: 8155928: Remove hardcoded port numbers from httpclient/Security.java test In-Reply-To: <572A7EB4.3000402@oracle.com> References: <57288F28.2000108@oracle.com> <89a44b75-7b8a-2cb7-da37-2c547b9aa987@Oracle.com> <572A1E04.8040906@oracle.com> <572A7EB4.3000402@oracle.com> Message-ID: <9F824031-6C20-403E-A0FB-235AA8F0F026@oracle.com> On 4 May 2016, at 23:59, Michael McMahon wrote: > I've just updated the webrev at > > http://cr.openjdk.java.net/~michaelm/8155928/webrev.3 > > to retry the tests in the unlikely event of a BindException Thanks Michael. This looks ok. -Chris. > - Michael > > On 04/05/16 19:12, Chris Hegarty wrote: >> Michael, >> >> getFreePort follows a failed pattern. There is no guarantee that the port will >> be ?free? when you actually require it. It will only reduce the likelihood of >> failure. Is there any way that the actual tests needing the port can >> create it themselves ( i understand that this will be more work, and possibly >> require some refactoring ). >> >> -Chris. >> >> >> On 4 May 2016, at 17:06, Michael McMahon wrote: >> >>> Hi Roger, >>> >>> Thanks for the review. That permission is not actually required for the >>> test. But, it did make me look closer at it, and I realised that permission >>> checking of the request URI port number was not being tested. So, that led me >>> down a couple of rat holes which is why I haven't replied till now. >>> >>> So, I have updated the webrev at: >>> >>> http://cr.openjdk.java.net/~michaelm/8155928/webrev.2/ >>> >>> to remove the redundant permission check and also the following changes >>> >>> 1) There was a bug in the permission check where the host part of the URI >>> was checked, but should have been the entire authority field. (Utils.java) >>> >>> 2) Add explicit test for a request URI and a real (randomly chosen) port number >>> (test 1 in Security.java) >>> >>> 3) Fixed another strange issue in the Security test which causes failures if the jtreg >>> work directory is not empty prior to running the test. (change in Security.moveFile) >>> >>> Thanks, >>> Michael >>> >>> On 03/05/16 15:47, Roger Riggs wrote: >>>> Hi Michael, >>>> >>>> test/java/net/httpclient/security/15.policy: line 15: >>>> >>>> - Should this policy file include the substitution for the ${port.number}? >>>> >>>> Otherwise, it still looks like it has a fixed port #. >>>> >>>> Roger >>>> >>>> >>>> On 5/3/2016 7:44 AM, Michael McMahon wrote: >>>>> Some tests with hardcoded port numbers were included in the initial http tests. >>>>> >>>>> The fix uses a driver to allocate a free port and pass it into the existing >>>>> security test through a system property. >>>>> >>>>> http://cr.openjdk.java.net/~michaelm/8155928/webrev.1/index.html >>>>> >>>>> Thanks, >>>>> Michael > From michael.x.mcmahon at oracle.com Thu May 5 11:29:57 2016 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Thu, 5 May 2016 12:29:57 +0100 Subject: RFR: 8155888: java/net/httpclient/QuickResponses.java intermittently failed with java.util.ConcurrentModificationException Message-ID: <572B2EB5.6020303@oracle.com> Another occasional test case failure. It's a concurrent modification exception caused by modifying a list during processing of the list (by the same thread). The solution is to keep separate lists of the modifications and to process them after the iterator completes. http://cr.openjdk.java.net/~michaelm/8155888/webrev.1/ Thanks Michael From pavel.rappo at oracle.com Thu May 5 11:47:07 2016 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Thu, 5 May 2016 12:47:07 +0100 Subject: RFR JDK-8087113: Websocket API and implementation In-Reply-To: References: Message-ID: > On 5 May 2016, at 00:20, Jitendra Kotamraju wrote: > > * I see that there is an issue for autoponging. May be this falls under it. The default impl of onPing() doesn't send PONG for *every* received PING. Yes, that's correct. The default implementation sends a Pong in response to a received Ping only if all the previous Pongs have been sent. > Since it is against the protocol semantics, it forces all applications to override the default onPing() impl. Is that right ? Strictly speaking, not sending a Pong for every Ping is not against the protocol semantics [1]: If an endpoint receives a Ping frame and has not yet sent Pong frame(s) in response to previous Ping frame(s), the endpoint MAY elect to send a Pong frame for only the most recently processed Ping frame. > It seems to me that the basic issue here is that API allows only one outstanding send operation. That is also limiting for applications as applications need to do more work. Yes, you're right saying that one outstanding write is an issue here and we're planning to go away from it [2]. For these same reasons you've stated. But that doesn't mean the default "autoponging" behaviour will change. It has its purpose. It protects the user from possible bloating of the outgoing queue. Imagine if the implementation would send a pong for every ping it receives and a rate with which pongs are sent is lower than a rate with which pings are received. That means that your outgoing queue will grow uncontrollably. And what's worse is that you won't even know about it. Because pings are not communicated to you (as that was the whole point of doing it automatically). Now, that could only happen if you don't correlate message requests with completion of send operations. But it is possible, and could be done easily. The API is designed to provide a reactive way of working. In other words, you get messages only if you ask for them. This way you fully control resources exhaustion on your side. But replying to every single ping opens a bypass to that mechanism. I think we should put a limit on the maximum number of queued automatic pongs. I'm not saying the limit should be strictly 1, but it should be a reasonable value. Think of it as of a pressure-relief safety valve. > * Since API allows these callback methods may be called by different threads, it is application responsibility to manage memory visibility and thread safety etc, right ? No, you don't need to manage memory visibility and there's no need to worry about concurrent executions, as listener's methods are never run concurrently. The API guarantees you all that: *

All methods are invoked in a sequential (and * * happens-before) order, one after another, possibly by different * threads. That's, of course, unless you decide to execute some task asynchronously from your listener. In which case you'll have to take care of all of the above by yourself. -------------------------------------------------------------------------------- [1] https://tools.ietf.org/html/rfc6455#section-5.5.3 [2] https://bugs.openjdk.java.net/browse/JDK-8155621 (WebSocket API tasks, item 12) From chris.hegarty at oracle.com Thu May 5 12:31:32 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 5 May 2016 13:31:32 +0100 Subject: RFR JDK-8087113: Websocket API and implementation In-Reply-To: References: Message-ID: <5E98283A-9D89-444D-8A05-6D8BB69F5C35@oracle.com> On 3 May 2016, at 16:23, Pavel Rappo wrote: > Hello, > > Here's an updated webrev with the latest implementation: > > http://cr.openjdk.java.net/~prappo/8087113/webrev.04/ This looks much better, more straight forward. I will ignore any TODO?s and items mentioned in 8155621, which I assume will be addressed as incremental improvements after this goes in. FWIW, I?m glad that you will be making simplifications around handling of TEXT. WSMessagePublisher - The Consumer that is passed to the sender, calls react() when a message is completed. It does this so that the removal and completion are done in a single place, but won?t this blow the stack if there is a continuous flow of outbound messages available? If so, would it be better to complete the future, remove from the backlog, and then signal ? WSShared - I see that there are number of simplifications that can be made once 8150785 is resolved. Good. Also, there us some overlap where with ByteBufferGenerator/Consumer, so there may be a future opportunity for consolidation, at least in some parts WSReceivedMessages - I think that the back pressure is implemented, correctly, as the number of invocations of the listener callbacks, but the spec may need a minor clarification. It is not a unit of message or frame. It can be as little as a single byte. Not an immediate issue, but we should revisit this as part of 8155621 -Chris. > If you're going to review it, please be advised that there is a number of known > API and implementation issues yet to be resolved [1]. More API tests will be > provided in the next couple of months. > > All applicable tests (1.1.1-10.1.1, 305 in total) from Autobahn Testsuite [2] > are green. > > Thanks, > -Pavel > > -------------------------------------------------------------------------------- > [1] https://bugs.openjdk.java.net/browse/JDK-8155621 > [2] http://autobahn.ws/testsuite/ > >> On 25 Mar 2016, at 16:21, Pavel Rappo wrote: >> >> Hi, >> >> Could you please review my change for JDK-8087113 >> >> http://cr.openjdk.java.net/~prappo/8087113/webrev.03/ >> >> This webrev contains initial implementation and basic tests for WebSocket API. >> Specification conformance & interoperability testing has been performed with >> Autobahn Testsuite [1]. As for API tests, I will provide more of them later. >> >> Thanks, >> -Pavel >> >> -------------------------------------------------------------------------------- >> [1] http://autobahn.ws/testsuite/ >> > From michael.x.mcmahon at oracle.com Thu May 5 16:21:56 2016 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Thu, 5 May 2016 17:21:56 +0100 Subject: RFR: 8153572: [JEP 110] IOException (connection closed for reading) is thrown when try to connect HTTPS service Message-ID: <572B7324.2060707@oracle.com> Simple change to set default use of TLSv1.2 when the user has not specified which protocols to use. http://cr.openjdk.java.net/~michaelm/8153572/webrev.1/ The change is in HttpClientImpl.java but also includes some logging additions. Thanks Michael From Roger.Riggs at Oracle.com Thu May 5 16:46:56 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 5 May 2016 12:46:56 -0400 Subject: RFR: 8153572: [JEP 110] IOException (connection closed for reading) is thrown when try to connect HTTPS service In-Reply-To: <572B7324.2060707@oracle.com> References: <572B7324.2060707@oracle.com> Message-ID: <233d0721-2337-cf10-f5b3-98edcacda03b@Oracle.com> Hi Michael, Looks fine. Editorial: test/java/net/httpclient/http2/java.httpclient/java/net/http/Http2TestExchange.java Line 8: wildcard import unnecdssary when only using SSLSession test/java/net/httpclient/http2/java.httpclient/java/net/http/Http2TestServerConnection.java Line 34: wildcard import unnecdssary when only using SSLSession Roger On 5/5/2016 12:21 PM, Michael McMahon wrote: > Simple change to set default use of TLSv1.2 when the user > has not specified which protocols to use. > > http://cr.openjdk.java.net/~michaelm/8153572/webrev.1/ > > The change is in HttpClientImpl.java but also includes some logging > additions. > > Thanks > Michael From jitsni at gmail.com Thu May 5 17:29:36 2016 From: jitsni at gmail.com (Jitendra Kotamraju) Date: Thu, 5 May 2016 10:29:36 -0700 Subject: RFR JDK-8087113: Websocket API and implementation In-Reply-To: References: Message-ID: Strictly speaking, not sending a Pong for every Ping is not against the protocol semantics [1]: If an endpoint receives a Ping frame and has not yet sent Pong frame(s) in response to previous Ping frame(s), the endpoint MAY elect to send a Pong frame for only the most recently processed Ping frame. Yes, that is true but it is also tricky. If the impl can guarantee that a Pong frame frame is sent for the *most recent* Ping frame, then it is ok. But not responding to the most recent Ping frame would cause problems. On Thu, May 5, 2016 at 4:47 AM, Pavel Rappo wrote: > > > On 5 May 2016, at 00:20, Jitendra Kotamraju wrote: > > > > * I see that there is an issue for autoponging. May be this falls under > it. The default impl of onPing() doesn't send PONG for *every* received > PING. > > Yes, that's correct. The default implementation sends a Pong in response > to a > received Ping only if all the previous Pongs have been sent. > > > Since it is against the protocol semantics, it forces all applications > to override the default onPing() impl. Is that right ? > > Strictly speaking, not sending a Pong for every Ping is not against the > protocol > semantics [1]: > > If an endpoint receives a Ping frame and has not yet sent Pong > frame(s) in response to previous Ping frame(s), the endpoint MAY > elect to send a Pong frame for only the most recently processed Ping > frame. > > > It seems to me that the basic issue here is that API allows only one > outstanding send operation. That is also limiting for applications as > applications need to do more work. > > Yes, you're right saying that one outstanding write is an issue here and > we're > planning to go away from it [2]. For these same reasons you've stated. But > that > doesn't mean the default "autoponging" behaviour will change. It has its > purpose. It protects the user from possible bloating of the outgoing queue. > > Imagine if the implementation would send a pong for every ping it receives > and a > rate with which pongs are sent is lower than a rate with which pings are > received. That means that your outgoing queue will grow uncontrollably. And > what's worse is that you won't even know about it. Because pings are not > communicated to you (as that was the whole point of doing it > automatically). > > Now, that could only happen if you don't correlate message requests with > completion of send operations. But it is possible, and could be done > easily. > > The API is designed to provide a reactive way of working. In other words, > you > get messages only if you ask for them. This way you fully control resources > exhaustion on your side. But replying to every single ping opens a bypass > to > that mechanism. > > I think we should put a limit on the maximum number of queued automatic > pongs. > I'm not saying the limit should be strictly 1, but it should be a > reasonable > value. Think of it as of a pressure-relief safety valve. > > > * Since API allows these callback methods may be called by different > threads, it is application responsibility to manage memory visibility and > thread safety etc, right ? > > No, you don't need to manage memory visibility and there's no need to worry > about concurrent executions, as listener's methods are never run > concurrently. > The API guarantees you all that: > > *

All methods are invoked in a sequential (and > * href="../../../java/util/concurrent/package-summary.html#MemoryVisibility"> > * happens-before) order, one after another, possibly by different > * threads. > > That's, of course, unless you decide to execute some task asynchronously > from > your listener. In which case you'll have to take care of all of the above > by > yourself. > > > -------------------------------------------------------------------------------- > [1] https://tools.ietf.org/html/rfc6455#section-5.5.3 > [2] https://bugs.openjdk.java.net/browse/JDK-8155621 (WebSocket API > tasks, item 12) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simone.bordet at gmail.com Thu May 5 20:28:58 2016 From: simone.bordet at gmail.com (Simone Bordet) Date: Thu, 5 May 2016 22:28:58 +0200 Subject: RFR JDK-8087113: Websocket API and implementation In-Reply-To: References: Message-ID: Hi, On Tue, May 3, 2016 at 5:23 PM, Pavel Rappo wrote: > > Hello, > > Here's an updated webrev with the latest implementation: > > http://cr.openjdk.java.net/~prappo/8087113/webrev.04/ Can you please summarize what's different from the previous ? I had a very quick look, but exception throwing, thread dispatching, multi-nested synchronization, incorrect handling of non-blocking writes (if I understand the code correctly) are still there. Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From pavel.rappo at oracle.com Thu May 5 21:29:31 2016 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Thu, 5 May 2016 22:29:31 +0100 Subject: RFR JDK-8087113: Websocket API and implementation In-Reply-To: References: Message-ID: Hello Simone, thanks again for looking into this! Generally speaking I took some time to get rid of multiple thread dispatching (incl. internal "Flow"s) and simplified the code a bit. I don't think it's a very practical thing to do, to get into all details as you could easily compare two consecutive webrevs (03/04) and will get much more fine-grained view. It's always a "single dispatch" now. Both on reading and writing sides. Whether or not it is worth spending more time _right now_ to turn it to a "zero dispatch" is a question. Devil is in detail and though it looks indeed less exhausting for a machine, it might mean quite a bit of extra programming now: security context checks depending on the calling thread, stack overflow problems due to a same-thread execution: request send request send ... etc. All these will require careful examination. I have put it in my TODO list [1]. Feel free to have a look at it, you may find there other ideas you've mentioned, including exceptions behaviour. I would like to proceed with initial push and continue working on improvements. -------------------------------------------------------------------------------- [1] https://bugs.openjdk.java.net/browse/JDK-8155621 > On 5 May 2016, at 21:28, Simone Bordet wrote: > > Hi, > > On Tue, May 3, 2016 at 5:23 PM, Pavel Rappo wrote: >> >> Hello, >> >> Here's an updated webrev with the latest implementation: >> >> http://cr.openjdk.java.net/~prappo/8087113/webrev.04/ > > Can you please summarize what's different from the previous ? > > I had a very quick look, but exception throwing, thread dispatching, > multi-nested synchronization, incorrect handling of non-blocking > writes (if I understand the code correctly) are still there. > > Thanks ! > > -- > Simone Bordet > http://bordet.blogspot.com > --- > Finally, no matter how good the architecture and design are, > to deliver bug-free software with optimal performance and reliability, > the implementation technique must be flawless. Victoria Livschitz From felix.yang at oracle.com Fri May 6 08:16:11 2016 From: felix.yang at oracle.com (Felix Yang) Date: Fri, 6 May 2016 16:16:11 +0800 Subject: RFR JDK-8087113: Websocket API and implementation In-Reply-To: References: Message-ID: <597254be-87a7-28bb-3b91-c3fc920cfb1e@oracle.com> Hi Pavel, several comments: 1. WebSocket.request(long n) is documented as " @throws IllegalArgumentException if n < -1 " It looks meaningless to allow 0. 2. Some concern on the way of handling close. Consider following scenario. * obtain a ws connection * message communications balabala... * initialize closing handshake on either client/server peer * if the client side didn't request adequate size or not requested at all, it actually doesn't know connection is closed. "onClose" will never be invoked, because close message is at the end of "queue". * it looks to me that: o the closing handshake can be blocked by UN-requested messages. o a websocket can be in a state that isClosed() return false but it can't send any message. Note that the state is not transient. Filed a bug https://bugs.openjdk.java.net/browse/JDK-8156191. It looks current design treats CloseMessage in similar way with other messages. I'm not sure if it is worth something like WSClosingHandshake. 3. I'm concerning the bug in #2 is side-effect of reactive mode. May I ask what is the benefit of reactive mode. WebSocket.request(long n) seem to be good in first glance but: * It looks end users need to calculate how many messages are expected. The another question comes o what messages will be taken into account. How about PING/PONG or else? * We may use request( a big value up to Long.MAX). But, in this case, why we need it? This looks simple but a bit problematic. My $0.02, Felix On 2016/5/3 23:23, Pavel Rappo wrote: > Hello, > > Here's an updated webrev with the latest implementation: > > http://cr.openjdk.java.net/~prappo/8087113/webrev.04/ > > If you're going to review it, please be advised that there is a number of known > API and implementation issues yet to be resolved [1]. More API tests will be > provided in the next couple of months. > > All applicable tests (1.1.1-10.1.1, 305 in total) from Autobahn Testsuite [2] > are green. > > Thanks, > -Pavel > > -------------------------------------------------------------------------------- > [1] https://bugs.openjdk.java.net/browse/JDK-8155621 > [2] http://autobahn.ws/testsuite/ > >> On 25 Mar 2016, at 16:21, Pavel Rappo wrote: >> >> Hi, >> >> Could you please review my change for JDK-8087113 >> >> http://cr.openjdk.java.net/~prappo/8087113/webrev.03/ >> >> This webrev contains initial implementation and basic tests for WebSocket API. >> Specification conformance & interoperability testing has been performed with >> Autobahn Testsuite [1]. As for API tests, I will provide more of them later. >> >> Thanks, >> -Pavel >> >> -------------------------------------------------------------------------------- >> [1] http://autobahn.ws/testsuite/ >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From pavel.rappo at oracle.com Fri May 6 10:53:00 2016 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Fri, 6 May 2016 11:53:00 +0100 Subject: RFR JDK-8087113: Websocket API and implementation In-Reply-To: <597254be-87a7-28bb-3b91-c3fc920cfb1e@oracle.com> References: <597254be-87a7-28bb-3b91-c3fc920cfb1e@oracle.com> Message-ID: <04E9FF9E-1610-44DC-B798-320D0B412BAB@oracle.com> > On 6 May 2016, at 09:16, Felix Yang wrote: > > Hi Pavel, > several comments: > > 1. WebSocket.request(long n) is documented as " > > @throws IllegalArgumentException if n < -1 > " > > It looks meaningless to allow 0. First of all, the way `request` is defined now is by no means meaningless. * @return resulting unfulfilled demand with this request taken into account */ long request(long n); Passing zero allows you, for instance, to get current demand without modifying it. But, this is going to be removed [1] (WebSocket API tasks, item 10). Think of the ability to pass 0 as of a degree of robustness. That's a corner case. It allows you to put some computed value, not necessarily a literal as it does not require you to check the value for 0. As far as it is non-negative, no harm is done. If you're still not convinced, consider any of the following: "abc".substring(1, 1); collection.removeAll(Collections.emptyList()); inputStream.read(new byte[0]); byteChannel.read(ByteBuffer.allocate(0)); > 2. Some concern on the way of handling close. Consider following scenario. > > ? obtain a ws connection > ? message communications balabala... > ? initialize closing handshake on either client/server peer > ? if the client side didn't request adequate size or not requested at all, it actually doesn't know connection is closed. "onClose" will never be invoked, because close message is at the end of "queue". True. That's the cost of providing reactive back-pressure. Otherwise we would have to read off the socket in the background looking for the Close message to appear. > ? it looks to me that: > ? the closing handshake can be blocked by UN-requested messages. > ? a websocket can be in a state that isClosed() return false but it can't send any message. Note that the state is not transient. WebSocket is not necessarily closed after you send a Close message: /** * Tells whether the {@code WebSocket} is closed. * *

A {@code WebSocket} deemed closed when either the underlying socket * is closed or the closing handshake is completed. * * @return {@code true} if the {@code WebSocket} is closed, * {@code false} otherwise */ boolean isClosed(); > Filed a bug https://bugs.openjdk.java.net/browse/JDK-8156191. It looks current design treats CloseMessage in similar way with other messages. I'm not sure if it is worth something like WSClosingHandshake. > 3. I'm concerning the bug in #2 is side-effect of reactive mode. May I ask what is the benefit of reactive mode. WebSocket.request(long n) seem to be good in first glance but: > ? It looks end users need to calculate how many messages are expected. The another question comes > ? what messages will be taken into account. How about PING/PONG or else? > ? We may use request( a big value up to Long.MAX). But, in this case, why we need it? This looks simple but a bit problematic. You can read on benefits of reactive mode here [2, 3]. And feel free to read the API thread [4] as well. -------------------------------------------------------------------------------- [1] https://bugs.openjdk.java.net/browse/JDK-8155621 [2] http://www.reactive-streams.org [3] https://github.com/reactive-streams/reactive-streams-jvm/ [4] http://mail.openjdk.java.net/pipermail/net-dev/2015-August/009077.html http://mail.openjdk.java.net/pipermail/net-dev/2015-September/009079.html http://mail.openjdk.java.net/pipermail/net-dev/2015-October/009223.html From chris.hegarty at oracle.com Fri May 6 17:04:17 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 6 May 2016 18:04:17 +0100 Subject: RFR: 8155888: java/net/httpclient/QuickResponses.java intermittently failed with java.util.ConcurrentModificationException In-Reply-To: <572B2EB5.6020303@oracle.com> References: <572B2EB5.6020303@oracle.com> Message-ID: On 5 May 2016, at 12:29, Michael McMahon wrote: > Another occasional test case failure. It's a concurrent modification exception caused > by modifying a list during processing of the list (by the same thread). The solution > is to keep separate lists of the modifications and to process them after the iterator > completes. > > http://cr.openjdk.java.net/~michaelm/8155888/webrev.1/ This looks ok to me Michael. -Chris. From Roger.Riggs at Oracle.com Fri May 6 17:05:35 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 6 May 2016 13:05:35 -0400 Subject: RFR: 8155888: java/net/httpclient/QuickResponses.java intermittently failed with java.util.ConcurrentModificationException In-Reply-To: References: <572B2EB5.6020303@oracle.com> Message-ID: +1 On 5/6/2016 1:04 PM, Chris Hegarty wrote: > On 5 May 2016, at 12:29, Michael McMahon wrote: > >> Another occasional test case failure. It's a concurrent modification exception caused >> by modifying a list during processing of the list (by the same thread). The solution >> is to keep separate lists of the modifications and to process them after the iterator >> completes. >> >> http://cr.openjdk.java.net/~michaelm/8155888/webrev.1/ > This looks ok to me Michael. > > -Chris. > From felix.yang at oracle.com Tue May 10 03:17:34 2016 From: felix.yang at oracle.com (Felix Yang) Date: Tue, 10 May 2016 11:17:34 +0800 Subject: RFR 8156509/9: Mark java/net/httpclient/security/Security.java as intermittently failing In-Reply-To: <573057A7.4090502@oracle.com> References: <573057A7.4090502@oracle.com> Message-ID: <6bcc3491-d010-d92c-5ed5-dd436fdac991@oracle.com> Hi there, please review the following patch to mark java/net/httpclient/security/Security.java with keyword 'intermittent'. It has been observed to fail intermittently. Thanks, Felix diff -r 2569a85ce76a test/java/net/httpclient/security/Security.java --- a/test/java/net/httpclient/security/Security.java Tue May 10 00:44:28 2016 +0000 +++ b/test/java/net/httpclient/security/Security.java Mon May 09 19:59:58 2016 -0700 @@ -25,6 +25,7 @@ /** * @test * @bug 8087112 + * @key intermittent * @library /lib/testlibrary/ * @build jdk.testlibrary.SimpleSSLContext * @compile ../../../../com/sun/net/httpserver/LogFilter.java -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.x.mcmahon at oracle.com Tue May 10 09:50:18 2016 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 10 May 2016 10:50:18 +0100 Subject: RFR 8156509/9: Mark java/net/httpclient/security/Security.java as intermittently failing In-Reply-To: <6bcc3491-d010-d92c-5ed5-dd436fdac991@oracle.com> References: <573057A7.4090502@oracle.com> <6bcc3491-d010-d92c-5ed5-dd436fdac991@oracle.com> Message-ID: <5731AEDA.5060500@oracle.com> I'd prefer to hold off with this change Felix. I recently pushed a change to that test which removes the hardcoded port numbers and also fixes another problem with the test. - Michael. On 10/05/16 04:17, Felix Yang wrote: > > Hi there, > > please review the following patch to mark > java/net/httpclient/security/Security.java with keyword > 'intermittent'. It has been observed to fail intermittently. > > Thanks, > > Felix > > diff -r 2569a85ce76a test/java/net/httpclient/security/Security.java > --- a/test/java/net/httpclient/security/Security.java Tue May 10 > 00:44:28 2016 +0000 > +++ b/test/java/net/httpclient/security/Security.java Mon May 09 > 19:59:58 2016 -0700 > @@ -25,6 +25,7 @@ > /** > * @test > * @bug 8087112 > + * @key intermittent > * @library /lib/testlibrary/ > * @build jdk.testlibrary.SimpleSSLContext > * @compile ../../../../com/sun/net/httpserver/LogFilter.java > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Tue May 10 09:54:43 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 10 May 2016 09:54:43 +0000 Subject: RFR(S): 8156521: Minor Fixes and cleanups in NetworkInterface.c Message-ID: <18ba30dd5f2444d4834665ec29b1d00b@DEWDFE13DE11.global.corp.sap> Hi all, can I please get a review for a change to NetworkInterface.c bugreport: https://bugs.openjdk.java.net/browse/JDK-8156521 webrev: http://cr.openjdk.java.net/~clanger/webrevs/8156521.0/ Apart from quite a few whitespace changes to clean up the coding, I went through and replaced all occurences of strcpy with strncpy as this was a finding of a code scanner that we used. Also in function "enumIPv6Interfaces" for Linux the local variable plen was changed from int to short. I ran builds on Linux, AIX, Solaris Sparc and Darwin to make sure nothing broke. Thanks in advance Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From vyom.tewari at oracle.com Tue May 10 10:06:23 2016 From: vyom.tewari at oracle.com (vyom) Date: Tue, 10 May 2016 15:36:23 +0530 Subject: RFR 8016521: InetAddress should not always re-order addresses returned from name service Message-ID: <5731B29F.8010806@oracle.com> Hi All, Please review the code changes for the below issue. Bug : JDK-8016521 : InetAddress should not always re-order addresses returned from name service Webrev : http://cr.openjdk.java.net/~vtewari/8016521/webrev0.0/index.html Thanks, Vyom From pavel.rappo at oracle.com Tue May 10 12:03:28 2016 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Tue, 10 May 2016 13:03:28 +0100 Subject: RFR JDK-8087113: Websocket API and implementation In-Reply-To: References: Message-ID: Hi Simone, > On 4 Apr 2016, at 20:07, Simone Bordet wrote: > > In my experience, once you get rid of exception throwing in async API > everything becomes much simpler, especially "deep" exceptions related > to invalid implementation internal states. Am I right saying that you propose that all exceptions (incl. NullPointerException, IllegalArgumentException, etc.) to be relayed through the CompletionStage rather than thrown in-place? > I see that the WebSocket implementation throws InternalError. > This is typically used for *JVM* failures, not application failures. > Applications are used to catch Exception, not Throwable, so > InternalError may not be handled well. > I suggest to not use Error or subclasses for application or > implementation failures, but Exception or subclasses instead. You're right. I knew that well when decided to use it. Look through the JDK code and you'll find that InternalError is used for cases like this very often. It's a de facto standard. Now, I'm not saying this is the right thing to do. But between finding my own way and being consistent with the rest of JDK I chose latter. As I understand there's no Throwable at the moment that is designed to allow a programmer to indicate their assumptions/assertions don't hold. Sometimes people (e.g. JUnit) use java.lang.AssertionError for this. But I don't think it's correct either. This error was designed to be used by the language `assert` construct. And throwing it from other contexts might give one a false impression that assertions are on, when they are in fact off. Maybe this error shouldn't have had public constructors. I don't know. All in all it's a good question to ask on core-libs-dev list: which Throwable should be assigned for cases like that? From ecki at zusammenkunft.net Tue May 10 19:52:28 2016 From: ecki at zusammenkunft.net (ecki at zusammenkunft.net) Date: Tue, 10 May 2016 21:52:28 +0200 Subject: RFR 8016521: InetAddress should not always re-order addresses returned from name service In-Reply-To: <5731B29F.8010806@oracle.com> References: <5731B29F.8010806@oracle.com> Message-ID: <2f153c27-44b3-49fd-9378-0aceedcd8249.maildroid@localhost> Hello, Love it. Not sure about two things, first of all if there are more test cases (especially assertions) needed and secondly how to handle the prefer=System case for anyAddr and local. Currently it seems to prefer v4 (since this is the current default) howver i would expect in the system case to either detect the prefered AF or use ipv6 (as of rfc). Returning 127.0.1/0.0.0.0 might actually make the system based address detection unuseable in v6 scenarios. Gruss Bernd -- http://bernd.eckenfels.net -----Original Message----- From: vyom To: net-dev Sent: Di., 10 Mai 2016 12:36 Subject: RFR 8016521: InetAddress should not always re-order addresses returned from name service Hi All, Please review the code changes for the below issue. Bug : JDK-8016521 : InetAddress should not always re-order addresses returned from name service Webrev : http://cr.openjdk.java.net/~vtewari/8016521/webrev0.0/index.html Thanks, Vyom From vyom.tewari at oracle.com Wed May 11 06:44:54 2016 From: vyom.tewari at oracle.com (vyom) Date: Wed, 11 May 2016 12:14:54 +0530 Subject: RFR 8154234: Examine if netdoc Handler can be removed Message-ID: <5732D4E6.8060905@oracle.com> Hi All, Please review the following simple fix for the issue(https://bugs.openjdk.java.net/browse/JDK-8154234). hg rm src/java.base/share/classes/sun/net/www/protocol/netdoc/Handler.java Thanks, Vyom From dmitry.samersoff at oracle.com Wed May 11 07:43:51 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 11 May 2016 10:43:51 +0300 Subject: RFR(S): 8156521: Minor Fixes and cleanups in NetworkInterface.c In-Reply-To: <18ba30dd5f2444d4834665ec29b1d00b@DEWDFE13DE11.global.corp.sap> References: <18ba30dd5f2444d4834665ec29b1d00b@DEWDFE13DE11.global.corp.sap> Message-ID: <5732E2B7.8010007@oracle.com> Christoph, Looks good for me (Reviewed). Few more space nits (no need to re-review) 1141 Missed space around = in i=0 1890 extra space after ( 2068 wrong indent -Dmitry On 2016-05-10 12:54, Langer, Christoph wrote: > Hi all, > > > > can I please get a review for a change to NetworkInterface.c > > > > bugreport: https://bugs.openjdk.java.net/browse/JDK-8156521 > > webrev: http://cr.openjdk.java.net/~clanger/webrevs/8156521.0/ > > > > Apart from quite a few whitespace changes to clean up the coding, I went > through and replaced all occurences of strcpy with strncpy as this was a > finding of a code scanner that we used. Also in function > ?enumIPv6Interfaces? for Linux the local variable plen was changed from > int to short. > > > > I ran builds on Linux, AIX, Solaris Sparc and Darwin to make sure > nothing broke. > > > > Thanks in advance > > Christoph > > > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From chris.hegarty at oracle.com Wed May 11 07:55:38 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 11 May 2016 08:55:38 +0100 Subject: RFR 8154234: Examine if netdoc Handler can be removed In-Reply-To: <5732D4E6.8060905@oracle.com> References: <5732D4E6.8060905@oracle.com> Message-ID: <74322ACA-81EA-4E88-BEDA-4C34617991B1@oracle.com> On 11 May 2016, at 07:44, vyom wrote: > Hi All, > > Please review the following simple fix for the issue(https://bugs.openjdk.java.net/browse/JDK-8154234). > > hg rm src/java.base/share/classes/sun/net/www/protocol/netdoc/Handler.java This seems fine to me Vyom. Thanks. -Chris. From chris.hegarty at oracle.com Wed May 11 08:50:10 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 11 May 2016 09:50:10 +0100 Subject: RFR(S): 8156521: Minor Fixes and cleanups in NetworkInterface.c In-Reply-To: <5732E2B7.8010007@oracle.com> References: <18ba30dd5f2444d4834665ec29b1d00b@DEWDFE13DE11.global.corp.sap> <5732E2B7.8010007@oracle.com> Message-ID: <6A9DC12B-3F6B-4FD5-AD12-852885B5176D@oracle.com> Hi Christoph, On 11 May 2016, at 08:43, Dmitry Samersoff wrote: >> ... >> bugreport: https://bugs.openjdk.java.net/browse/JDK-8156521 >> >> webrev: http://cr.openjdk.java.net/~clanger/webrevs/8156521.0/ I think this is mainly fine, and good to have such cleanup in this area. I agree with the replacement of strcpy with strncpy, but I think we should explicitly null terminate in case the src is greater or equal to the dst buffer size. This is done elsewhere in this file too, e.g. strncpy(buf, input, sizeof(buf) - 1); buf[sizeof(buf) - 1] = '\0'; >> Apart from quite a few whitespace changes to clean up the coding, I went >> through and replaced all occurences of strcpy with strncpy as this was a >> finding of a code scanner that we used. Also in function >> ?enumIPv6Interfaces? for Linux the local variable plen was changed from >> int to short. Why was this done for plen specifically, and not scope, or others ? -Chris. From Alan.Bateman at oracle.com Wed May 11 08:56:38 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 11 May 2016 09:56:38 +0100 Subject: RFR(S): 8156521: Minor Fixes and cleanups in NetworkInterface.c In-Reply-To: <6A9DC12B-3F6B-4FD5-AD12-852885B5176D@oracle.com> References: <18ba30dd5f2444d4834665ec29b1d00b@DEWDFE13DE11.global.corp.sap> <5732E2B7.8010007@oracle.com> <6A9DC12B-3F6B-4FD5-AD12-852885B5176D@oracle.com> Message-ID: <5732F3C6.1000707@oracle.com> On 11/05/2016 09:50, Chris Hegarty wrote: > Hi Christoph, > > On 11 May 2016, at 08:43, Dmitry Samersoff wrote: > >>> ... >>> bugreport: https://bugs.openjdk.java.net/browse/JDK-8156521 >>> >>> webrev: http://cr.openjdk.java.net/~clanger/webrevs/8156521.0/ > I think this is mainly fine, and good to have such cleanup in this area. > I agree on the clean-up. It would be great if we could use the opportunity to clean-up the annoying long lines that have crept into this code recently, this would avoid too much horizontal scrolling when looks at the changes side-by-side. -Alan. From christoph.langer at sap.com Wed May 11 09:21:10 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 11 May 2016 09:21:10 +0000 Subject: RFR(S): 8156521: Minor Fixes and cleanups in NetworkInterface.c In-Reply-To: <6A9DC12B-3F6B-4FD5-AD12-852885B5176D@oracle.com> References: <18ba30dd5f2444d4834665ec29b1d00b@DEWDFE13DE11.global.corp.sap> <5732E2B7.8010007@oracle.com> <6A9DC12B-3F6B-4FD5-AD12-852885B5176D@oracle.com> Message-ID: <588139064be7405ba3abecef05cb3fb7@DEWDFE13DE11.global.corp.sap> Hi, @Chris: As for your points: > I agree with the replacement of strcpy with strncpy, but I think we should > explicitly null terminate in case the src is greater or equal to the dst buffer > size. This is done elsewhere in this file too, e.g. > > strncpy(buf, input, sizeof(buf) - 1); > buf[sizeof(buf) - 1] = '\0'; There are 2 different patterns of strncpy usage in this code. One is where we would use strncpy giving the full buffer length and eventually setting the last byte to 0 to make sure the string is terminated. The other pattern is where a memset to 0 of the buffer was done before. So I thought it's fine here to give strncpy "buffersize - 1" as length since per its documentation it would copy all characters up to bufferlen and not terminate with 0 if strlen is >= bufferlen. That makes sense? > >> Apart from quite a few whitespace changes to clean up the coding, I went > >> through and replaced all occurences of strcpy with strncpy as this was a > >> finding of a code scanner that we used. Also in function > >> "enumIPv6Interfaces" for Linux the local variable plen was changed from > >> int to short. > > Why was this done for plen specifically, and not scope, or others ? In struct _netaddr the mask field is defined as short and hence short is expected by the addif function. So plen should be a short in enumIPv6Interfaces for Linux, too. While looking again I see that the BSD function "static int prefix(void *val, int size)" should also rather be a "static short prefix(void *val, int size)". Shall I update this as well? @Alan: As for the line length: If I get the feedback on those 2 points I'll prepare a new webrev to shorten some lines. @Dmitry: Will also work in your findings in the update... Thanks for all the feedback Christoph From chris.hegarty at oracle.com Wed May 11 10:25:01 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 11 May 2016 11:25:01 +0100 Subject: RFR(S): 8156521: Minor Fixes and cleanups in NetworkInterface.c In-Reply-To: <588139064be7405ba3abecef05cb3fb7@DEWDFE13DE11.global.corp.sap> References: <18ba30dd5f2444d4834665ec29b1d00b@DEWDFE13DE11.global.corp.sap> <5732E2B7.8010007@oracle.com> <6A9DC12B-3F6B-4FD5-AD12-852885B5176D@oracle.com> <588139064be7405ba3abecef05cb3fb7@DEWDFE13DE11.global.corp.sap> Message-ID: <1732F6B2-AC99-41B5-BCC7-2D164FB20716@oracle.com> On 11 May 2016, at 10:21, Langer, Christoph wrote: > Hi, > > @Chris: As for your points: > >> I agree with the replacement of strcpy with strncpy, but I think we should >> explicitly null terminate in case the src is greater or equal to the dst buffer >> size. This is done elsewhere in this file too, e.g. >> >> strncpy(buf, input, sizeof(buf) - 1); >> buf[sizeof(buf) - 1] = '\0'; > > There are 2 different patterns of strncpy usage in this code. One is where we would use strncpy giving the full buffer length and eventually setting the last byte to 0 to make sure the string is terminated. The other pattern is where a memset to 0 of the buffer was done before. So I thought it's fine here to give strncpy "buffersize - 1" as length since per its documentation it would copy all characters up to bufferlen and not terminate with 0 if strlen is >= bufferlen. That makes sense? It does. It was not clear to me that we were calling memset for ALL of these cases when I made the comment, but I carefully checked all your changes from strcpy to strncpy, and they do indeed look fine. >>>> Apart from quite a few whitespace changes to clean up the coding, I went >>>> through and replaced all occurences of strcpy with strncpy as this was a >>>> finding of a code scanner that we used. Also in function >>>> "enumIPv6Interfaces" for Linux the local variable plen was changed from >>>> int to short. >> >> Why was this done for plen specifically, and not scope, or others ? > > In struct _netaddr the mask field is defined as short and hence short is expected by the addif function. So plen should be a short in enumIPv6Interfaces for Linux, too. Ok, that?s fine. > While looking again I see that the BSD function "static int prefix(void *val, int size)" should also rather be a "static short prefix(void *val, int size)". Shall I update this as well? Probably. > @Alan: As for the line length: If I get the feedback on those 2 points I'll prepare a new webrev to shorten some lines. That would be great, thanks. -Chris. From mark.sheppard at oracle.com Wed May 11 11:12:28 2016 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Wed, 11 May 2016 12:12:28 +0100 Subject: RFR(S): 8156521: Minor Fixes and cleanups in NetworkInterface.c In-Reply-To: <6A9DC12B-3F6B-4FD5-AD12-852885B5176D@oracle.com> References: <18ba30dd5f2444d4834665ec29b1d00b@DEWDFE13DE11.global.corp.sap> <5732E2B7.8010007@oracle.com> <6A9DC12B-3F6B-4FD5-AD12-852885B5176D@oracle.com> Message-ID: <4b8ae34f-5e3c-50df-9086-eb74bf48a679@oracle.com> the declaration in of plen (also scope and dad_status) as an int in enumIPv6Interfaces would appear to be done to align with its use in fscanf, even though it is a two character conversion. So would it not be more appropriate to cast it as a short when passed to addif ? the name plen would also convey a variable containing a length, but that doesn't appear to be the purpose of plen. a more appropriate name would be more informative in the code regards Mark On 11/05/2016 09:50, Chris Hegarty wrote: > Hi Christoph, > > On 11 May 2016, at 08:43, Dmitry Samersoff wrote: > >>> ... >>> bugreport: https://bugs.openjdk.java.net/browse/JDK-8156521 >>> >>> webrev: http://cr.openjdk.java.net/~clanger/webrevs/8156521.0/ > I think this is mainly fine, and good to have such cleanup in this area. > > I agree with the replacement of strcpy with strncpy, but I think we should > explicitly null terminate in case the src is greater or equal to the dst buffer > size. This is done elsewhere in this file too, e.g. > > strncpy(buf, input, sizeof(buf) - 1); > buf[sizeof(buf) - 1] = '\0'; > > >>> Apart from quite a few whitespace changes to clean up the coding, I went >>> through and replaced all occurences of strcpy with strncpy as this was a >>> finding of a code scanner that we used. Also in function >>> ?enumIPv6Interfaces? for Linux the local variable plen was changed from >>> int to short. > Why was this done for plen specifically, and not scope, or others ? > > -Chris. From christoph.langer at sap.com Wed May 11 21:27:26 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 11 May 2016 21:27:26 +0000 Subject: RFR(S): 8156521: Minor Fixes and cleanups in NetworkInterface.c In-Reply-To: <1732F6B2-AC99-41B5-BCC7-2D164FB20716@oracle.com> References: <18ba30dd5f2444d4834665ec29b1d00b@DEWDFE13DE11.global.corp.sap> <5732E2B7.8010007@oracle.com> <6A9DC12B-3F6B-4FD5-AD12-852885B5176D@oracle.com> <588139064be7405ba3abecef05cb3fb7@DEWDFE13DE11.global.corp.sap> <1732F6B2-AC99-41B5-BCC7-2D164FB20716@oracle.com> Message-ID: Hi again, I'm done with the new version: http://cr.openjdk.java.net/~clanger/webrevs/8156521.1/ I now tried to break lines that are too long and also fixed some other space and indentation issues. To incorporate Mark's suggestions regarding plen in enumIPv6Interfaces, I consistently renamed it to "prefix" in all places, also in the prefix function for BSD. I also reverted back to scanf as int but then cast prefix to short on all relevant calls to addif. I verified the build on Linux, AIX, Solaris and MAC and ran a basic NetworkInterface test to list interfaces and print addresses and attributes. I think I'm done. Chris, would you be so kind to push it when you consider it reviewed? I'm still only author. Thanks and best regards Christoph > -----Original Message----- > From: Chris Hegarty [mailto:chris.hegarty at oracle.com] > Sent: Mittwoch, 11. Mai 2016 12:25 > To: Langer, Christoph > Cc: Alan Bateman ; Dmitry Samersoff > ; net-dev at openjdk.java.net > Subject: Re: RFR(S): 8156521: Minor Fixes and cleanups in NetworkInterface.c > > > On 11 May 2016, at 10:21, Langer, Christoph > wrote: > > > Hi, > > > > @Chris: As for your points: > > > >> I agree with the replacement of strcpy with strncpy, but I think we should > >> explicitly null terminate in case the src is greater or equal to the dst buffer > >> size. This is done elsewhere in this file too, e.g. > >> > >> strncpy(buf, input, sizeof(buf) - 1); > >> buf[sizeof(buf) - 1] = '\0'; > > > > There are 2 different patterns of strncpy usage in this code. One is where we > would use strncpy giving the full buffer length and eventually setting the last > byte to 0 to make sure the string is terminated. The other pattern is where a > memset to 0 of the buffer was done before. So I thought it's fine here to give > strncpy "buffersize - 1" as length since per its documentation it would copy all > characters up to bufferlen and not terminate with 0 if strlen is >= bufferlen. > That makes sense? > > It does. It was not clear to me that we were calling memset for ALL of these > cases > when I made the comment, but I carefully checked all your changes from strcpy > to > strncpy, and they do indeed look fine. > > >>>> Apart from quite a few whitespace changes to clean up the coding, I went > >>>> through and replaced all occurences of strcpy with strncpy as this was a > >>>> finding of a code scanner that we used. Also in function > >>>> "enumIPv6Interfaces" for Linux the local variable plen was changed from > >>>> int to short. > >> > >> Why was this done for plen specifically, and not scope, or others ? > > > > In struct _netaddr the mask field is defined as short and hence short is > expected by the addif function. So plen should be a short in enumIPv6Interfaces > for Linux, too. > > Ok, that's fine. > > > While looking again I see that the BSD function "static int prefix(void *val, int > size)" should also rather be a "static short prefix(void *val, int size)". Shall I > update this as well? > > Probably. > > > @Alan: As for the line length: If I get the feedback on those 2 points I'll > prepare a new webrev to shorten some lines. > > That would be great, thanks. > > -Chris. From doychin at dsoft-bg.com Thu May 12 10:19:04 2016 From: doychin at dsoft-bg.com (Doychin Bondzhev) Date: Thu, 12 May 2016 13:19:04 +0300 Subject: Reminder about reported problem in NetworkInterface.c Message-ID: Hi, guys I see that some of you is working on NetworkInterface.c file. Just posting this to remind that there is a problem in NetworkInterface.c when scanning network interfaces on Linux platform. Here is the initial report from January 2015. http://mail.openjdk.java.net/pipermail/net-dev/2015-January/008829.html Can someone open a bug report for this? thanks in advance -- Doychin Bondzhev dSoft-Bulgaria Ltd. PowerPro - billing & provisioning solution for Service providers PowerStor - Warehouse & POS http://www.dsoft-bg.com/ Mobile: +359888243116 -------------- next part -------------- A non-text attachment was scrubbed... Name: doychin.vcf Type: text/x-vcard Size: 268 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5944 bytes Desc: S/MIME Cryptographic Signature URL: From christoph.langer at sap.com Thu May 12 10:25:03 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 12 May 2016 10:25:03 +0000 Subject: Reminder about reported problem in NetworkInterface.c In-Reply-To: References: Message-ID: Hi Doychin, thanks for pointing me to this. I was already looking at that part of the code and know about some gaps. So I'll take this item and open a bug and work on integrating the proposed change. I'll probably be able to start working on this next week. But before that my fix for Bug 8156521 has to be finished and pushed. Best regards Christoph > -----Original Message----- > From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of > Doychin Bondzhev > Sent: Donnerstag, 12. Mai 2016 12:19 > To: net-dev at openjdk.java.net > Subject: Reminder about reported problem in NetworkInterface.c > > * PGP - S/MIME Signed by an unverified key: 12.05.2016 at 12:19:04 > > Hi, guys > > I see that some of you is working on NetworkInterface.c file. > > Just posting this to remind that there is a problem in > NetworkInterface.c when scanning network interfaces on Linux platform. > > Here is the initial report from January 2015. > > http://mail.openjdk.java.net/pipermail/net-dev/2015-January/008829.html > > Can someone open a bug report for this? > > thanks in advance > -- > Doychin Bondzhev > dSoft-Bulgaria Ltd. > PowerPro - billing & provisioning solution for Service providers > PowerStor - Warehouse & POS > http://www.dsoft-bg.com/ > Mobile: +359888243116 > > * doychin at dsoft-bg.com > * Issuer: StartCom Ltd. - Unverified From Alan.Bateman at oracle.com Thu May 12 10:31:33 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 12 May 2016 11:31:33 +0100 Subject: Reminder about reported problem in NetworkInterface.c In-Reply-To: References: Message-ID: <57345B85.6040608@oracle.com> On 12/05/2016 11:25, Langer, Christoph wrote: > Hi Doychin, > > thanks for pointing me to this. I was already looking at that part of the code and know about some gaps. So I'll take this item and open a bug and work on integrating the proposed change. > > I don't see Doychin on the of OCA signatories so I don't think we can accept the contribution without getting that sorted out. It might be that he is is listed with a different name or a company name of course. Creating a bug and fixing it should be fine of course. -Alan From chris.hegarty at oracle.com Thu May 12 10:42:56 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 12 May 2016 11:42:56 +0100 Subject: RFR(S): 8156521: Minor Fixes and cleanups in NetworkInterface.c In-Reply-To: References: <18ba30dd5f2444d4834665ec29b1d00b@DEWDFE13DE11.global.corp.sap> <5732E2B7.8010007@oracle.com> <6A9DC12B-3F6B-4FD5-AD12-852885B5176D@oracle.com> <588139064be7405ba3abecef05cb3fb7@DEWDFE13DE11.global.corp.sap> <1732F6B2-AC99-41B5-BCC7-2D164FB20716@oracle.com> Message-ID: <9AC8C5F1-9148-43F3-BEE5-78FDA1169623@oracle.com> On 11 May 2016, at 22:27, Langer, Christoph wrote: > Hi again, > > I'm done with the new version: http://cr.openjdk.java.net/~clanger/webrevs/8156521.1/ > > I now tried to break lines that are too long and also fixed some other space and indentation issues. > > To incorporate Mark's suggestions regarding plen in enumIPv6Interfaces, I consistently renamed it to "prefix" in all places, also in the prefix function for BSD. I also reverted back to scanf as int but then cast prefix to short on all relevant calls to addif. > > I verified the build on Linux, AIX, Solaris and MAC and ran a basic NetworkInterface test to list interfaces and print addresses and attributes. I think I'm done. > > Chris, would you be so kind to push it when you consider it reviewed? I'm still only author. I will take a final pass over the updated webrev, do some testing, and then push it for you. -Chris. > Thanks and best regards > Christoph > > >> -----Original Message----- >> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >> Sent: Mittwoch, 11. Mai 2016 12:25 >> To: Langer, Christoph >> Cc: Alan Bateman ; Dmitry Samersoff >> ; net-dev at openjdk.java.net >> Subject: Re: RFR(S): 8156521: Minor Fixes and cleanups in NetworkInterface.c >> >> >> On 11 May 2016, at 10:21, Langer, Christoph >> wrote: >> >>> Hi, >>> >>> @Chris: As for your points: >>> >>>> I agree with the replacement of strcpy with strncpy, but I think we should >>>> explicitly null terminate in case the src is greater or equal to the dst buffer >>>> size. This is done elsewhere in this file too, e.g. >>>> >>>> strncpy(buf, input, sizeof(buf) - 1); >>>> buf[sizeof(buf) - 1] = '\0'; >>> >>> There are 2 different patterns of strncpy usage in this code. One is where we >> would use strncpy giving the full buffer length and eventually setting the last >> byte to 0 to make sure the string is terminated. The other pattern is where a >> memset to 0 of the buffer was done before. So I thought it's fine here to give >> strncpy "buffersize - 1" as length since per its documentation it would copy all >> characters up to bufferlen and not terminate with 0 if strlen is >= bufferlen. >> That makes sense? >> >> It does. It was not clear to me that we were calling memset for ALL of these >> cases >> when I made the comment, but I carefully checked all your changes from strcpy >> to >> strncpy, and they do indeed look fine. >> >>>>>> Apart from quite a few whitespace changes to clean up the coding, I went >>>>>> through and replaced all occurences of strcpy with strncpy as this was a >>>>>> finding of a code scanner that we used. Also in function >>>>>> "enumIPv6Interfaces" for Linux the local variable plen was changed from >>>>>> int to short. >>>> >>>> Why was this done for plen specifically, and not scope, or others ? >>> >>> In struct _netaddr the mask field is defined as short and hence short is >> expected by the addif function. So plen should be a short in enumIPv6Interfaces >> for Linux, too. >> >> Ok, that's fine. >> >>> While looking again I see that the BSD function "static int prefix(void *val, int >> size)" should also rather be a "static short prefix(void *val, int size)". Shall I >> update this as well? >> >> Probably. >> >>> @Alan: As for the line length: If I get the feedback on those 2 points I'll >> prepare a new webrev to shorten some lines. >> >> That would be great, thanks. >> >> -Chris. From christoph.langer at sap.com Thu May 12 11:00:07 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 12 May 2016 11:00:07 +0000 Subject: RFR(S): 8156521: Minor Fixes and cleanups in NetworkInterface.c In-Reply-To: <9AC8C5F1-9148-43F3-BEE5-78FDA1169623@oracle.com> References: <18ba30dd5f2444d4834665ec29b1d00b@DEWDFE13DE11.global.corp.sap> <5732E2B7.8010007@oracle.com> <6A9DC12B-3F6B-4FD5-AD12-852885B5176D@oracle.com> <588139064be7405ba3abecef05cb3fb7@DEWDFE13DE11.global.corp.sap> <1732F6B2-AC99-41B5-BCC7-2D164FB20716@oracle.com> <9AC8C5F1-9148-43F3-BEE5-78FDA1169623@oracle.com> Message-ID: Thanks Chris. When you finally wrap it up, maybe you want to have a look at one thing which I didn't dare to clean up. In line 28 you find: #if defined(_ALLBSD_SOURCE) && defined(__OpenBSD__) #include #endif But will also be included unconditionally for all platforms in line 34. So maybe this part for OpenBSD could be removed. It would change the include order on OpenBSD, of course. As I don't have an OpenBSD build environment I decided not to touch this but you could remove it if you have more confidence... Best regards Christoph > -----Original Message----- > From: Chris Hegarty [mailto:chris.hegarty at oracle.com] > Sent: Donnerstag, 12. Mai 2016 12:43 > To: Langer, Christoph > Cc: Alan Bateman ; Dmitry Samersoff > ; Mark Sheppard > ; net-dev at openjdk.java.net > Subject: Re: RFR(S): 8156521: Minor Fixes and cleanups in NetworkInterface.c > > On 11 May 2016, at 22:27, Langer, Christoph > wrote: > > > Hi again, > > > > I'm done with the new version: > http://cr.openjdk.java.net/~clanger/webrevs/8156521.1/ > > > > I now tried to break lines that are too long and also fixed some other space > and indentation issues. > > > > To incorporate Mark's suggestions regarding plen in enumIPv6Interfaces, I > consistently renamed it to "prefix" in all places, also in the prefix function for > BSD. I also reverted back to scanf as int but then cast prefix to short on all > relevant calls to addif. > > > > I verified the build on Linux, AIX, Solaris and MAC and ran a basic > NetworkInterface test to list interfaces and print addresses and attributes. I > think I'm done. > > > > Chris, would you be so kind to push it when you consider it reviewed? I'm still > only author. > > I will take a final pass over the updated webrev, do some testing, and then > push it for you. > > -Chris. > > > Thanks and best regards > > Christoph > > > > > >> -----Original Message----- > >> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] > >> Sent: Mittwoch, 11. Mai 2016 12:25 > >> To: Langer, Christoph > >> Cc: Alan Bateman ; Dmitry Samersoff > >> ; net-dev at openjdk.java.net > >> Subject: Re: RFR(S): 8156521: Minor Fixes and cleanups in > NetworkInterface.c > >> > >> > >> On 11 May 2016, at 10:21, Langer, Christoph > >> wrote: > >> > >>> Hi, > >>> > >>> @Chris: As for your points: > >>> > >>>> I agree with the replacement of strcpy with strncpy, but I think we should > >>>> explicitly null terminate in case the src is greater or equal to the dst > buffer > >>>> size. This is done elsewhere in this file too, e.g. > >>>> > >>>> strncpy(buf, input, sizeof(buf) - 1); > >>>> buf[sizeof(buf) - 1] = '\0'; > >>> > >>> There are 2 different patterns of strncpy usage in this code. One is where > we > >> would use strncpy giving the full buffer length and eventually setting the last > >> byte to 0 to make sure the string is terminated. The other pattern is where a > >> memset to 0 of the buffer was done before. So I thought it's fine here to give > >> strncpy "buffersize - 1" as length since per its documentation it would copy > all > >> characters up to bufferlen and not terminate with 0 if strlen is >= bufferlen. > >> That makes sense? > >> > >> It does. It was not clear to me that we were calling memset for ALL of these > >> cases > >> when I made the comment, but I carefully checked all your changes from > strcpy > >> to > >> strncpy, and they do indeed look fine. > >> > >>>>>> Apart from quite a few whitespace changes to clean up the coding, I > went > >>>>>> through and replaced all occurences of strcpy with strncpy as this was a > >>>>>> finding of a code scanner that we used. Also in function > >>>>>> "enumIPv6Interfaces" for Linux the local variable plen was changed > from > >>>>>> int to short. > >>>> > >>>> Why was this done for plen specifically, and not scope, or others ? > >>> > >>> In struct _netaddr the mask field is defined as short and hence short is > >> expected by the addif function. So plen should be a short in > enumIPv6Interfaces > >> for Linux, too. > >> > >> Ok, that's fine. > >> > >>> While looking again I see that the BSD function "static int prefix(void *val, > int > >> size)" should also rather be a "static short prefix(void *val, int size)". Shall I > >> update this as well? > >> > >> Probably. > >> > >>> @Alan: As for the line length: If I get the feedback on those 2 points I'll > >> prepare a new webrev to shorten some lines. > >> > >> That would be great, thanks. > >> > >> -Chris. From ivan.st.ivanov at gmail.com Thu May 12 11:18:11 2016 From: ivan.st.ivanov at gmail.com (Ivan St. Ivanov) Date: Thu, 12 May 2016 14:18:11 +0300 Subject: Reminder about reported problem in NetworkInterface.c In-Reply-To: <57345B85.6040608@oracle.com> References: <57345B85.6040608@oracle.com> Message-ID: Hello Alan, If that is the showstopper for moving this change forward, Doychin is part of the Bulgarian JUG. Which has signed the OCA. I talked to him and he is fine to let his change pass through JUG's account. Regards, Ivan On May 12, 2016 13:32, "Alan Bateman" wrote: > > > On 12/05/2016 11:25, Langer, Christoph wrote: > >> Hi Doychin, >> >> thanks for pointing me to this. I was already looking at that part of the >> code and know about some gaps. So I'll take this item and open a bug and >> work on integrating the proposed change. >> >> >> I don't see Doychin on the of OCA signatories so I don't think we can > accept the contribution without getting that sorted out. It might be that > he is is listed with a different name or a company name of course. > > Creating a bug and fixing it should be fine of course. > > -Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.x.mcmahon at oracle.com Thu May 12 13:43:30 2016 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Thu, 12 May 2016 14:43:30 +0100 Subject: RFR 8156801: java/net/httpclient/security/Driver.java failed with RuntimeException: Non zero return value Message-ID: <57348882.3020706@oracle.com> This test is still failing intermittently. The reason is that one of the places where BindException can be thrown is called by reflection. So, the exception is wrapped in an InvocationTargetException and needs to be unwrapped. http://cr.openjdk.java.net/~michaelm/8156801/webrev.1/ Thanks, Michael From chris.hegarty at oracle.com Thu May 12 14:03:39 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 12 May 2016 15:03:39 +0100 Subject: RFR 8156801: java/net/httpclient/security/Driver.java failed with RuntimeException: Non zero return value In-Reply-To: <57348882.3020706@oracle.com> References: <57348882.3020706@oracle.com> Message-ID: <54E00DDE-938B-42C2-AB1B-6B46F6E73E5A@oracle.com> On 12 May 2016, at 14:43, Michael McMahon wrote: > This test is still failing intermittently. The reason is that one of the places where BindException > can be thrown is called by reflection. So, the exception is wrapped in an InvocationTargetException > and needs to be unwrapped. > > http://cr.openjdk.java.net/~michaelm/8156801/webrev.1/ Looks ok Michael. -Chris. From pavel.rappo at oracle.com Thu May 12 14:05:42 2016 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Thu, 12 May 2016 15:05:42 +0100 Subject: RFR 8156801: java/net/httpclient/security/Driver.java failed with RuntimeException: Non zero return value In-Reply-To: <57348882.3020706@oracle.com> References: <57348882.3020706@oracle.com> Message-ID: Hi Michael, Is there any reason why you don't throw the wrapped `Throwable` unconditionally? Thanks. @@ -144,14 +144,11 @@ } } - static Object getProxy(int port, boolean b) throws Exception { + static Object getProxy(int port, boolean b) throws Throwable { try { return proxyConstructor.newInstance(port, b); } catch (InvocationTargetException e) { - Throwable t = e.getTargetException(); - if (t instanceof BindException) - throw (BindException) t; - throw e; + throw e.getCause(); } } @@ -331,7 +328,7 @@ } catch (BindException e) { System.out.println("Bind failed"); throw e; - } catch (Exception ee) { + } catch (Throwable ee) { throw new RuntimeException(ee); } System.out.println("Proxy port = " + proxyPort); > On 12 May 2016, at 14:43, Michael McMahon wrote: > > This test is still failing intermittently. The reason is that one of the places where BindException > can be thrown is called by reflection. So, the exception is wrapped in an InvocationTargetException > and needs to be unwrapped. > > http://cr.openjdk.java.net/~michaelm/8156801/webrev.1/ > > Thanks, > Michael From chris.hegarty at oracle.com Thu May 12 15:32:10 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 12 May 2016 16:32:10 +0100 Subject: JDK-8148424 Support IPv6-only Unix environments Message-ID: <02A5EAA0-C1AB-47C3-8D06-7DA16EC5458E@oracle.com> Martin, Promoted by some other changes that are going on, I stumbled across your proposal for 8148424: "Support IPv6-only Unix environments? [1][2][3]. I think the changes are good. I rebased them against the latest source in jdk9/dev. http://cr.openjdk.java.net/~chegar/8148424/ I put the changes through our build and test system, and there are no surprising results. Have you done much testing of the change in your environment? -Chris [1] http://mail.openjdk.java.net/pipermail/nio-dev/2016-January/003509.html [2] http://cr.openjdk.java.net/~martin/webrevs/openjdk9/ipv6-only/ [3] https://bugs.openjdk.java.net/browse/JDK-8148424 From chris.hegarty at oracle.com Thu May 12 15:36:01 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 12 May 2016 16:36:01 +0100 Subject: RFR(S): 8156521: Minor Fixes and cleanups in NetworkInterface.c In-Reply-To: References: <18ba30dd5f2444d4834665ec29b1d00b@DEWDFE13DE11.global.corp.sap> <5732E2B7.8010007@oracle.com> <6A9DC12B-3F6B-4FD5-AD12-852885B5176D@oracle.com> <588139064be7405ba3abecef05cb3fb7@DEWDFE13DE11.global.corp.sap> <1732F6B2-AC99-41B5-BCC7-2D164FB20716@oracle.com> <9AC8C5F1-9148-43F3-BEE5-78FDA1169623@oracle.com> Message-ID: <81CF3E8F-FE4E-477E-A661-A58FF316ABF1@oracle.com> Pushed, with a few additional stylistic edits. http://hg.openjdk.java.net/jdk9/dev/jdk/rev/fe3e1508653e On 12 May 2016, at 12:00, Langer, Christoph wrote: > Thanks Chris. > > When you finally wrap it up, maybe you want to have a look at one thing which I didn't dare to clean up. In line 28 you find: > > #if defined(_ALLBSD_SOURCE) && defined(__OpenBSD__) > #include > #endif I omitted this from the current set of cleanups. It can be done later, if needed. -Chris. > But will also be included unconditionally for all platforms in line 34. So maybe this part for OpenBSD could be removed. > It would change the include order on OpenBSD, of course. As I don't have an OpenBSD build environment I decided not to touch this but you could remove it if you have more confidence... > > Best regards > Christoph > > >> -----Original Message----- >> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >> Sent: Donnerstag, 12. Mai 2016 12:43 >> To: Langer, Christoph >> Cc: Alan Bateman ; Dmitry Samersoff >> ; Mark Sheppard >> ; net-dev at openjdk.java.net >> Subject: Re: RFR(S): 8156521: Minor Fixes and cleanups in NetworkInterface.c >> >> On 11 May 2016, at 22:27, Langer, Christoph >> wrote: >> >>> Hi again, >>> >>> I'm done with the new version: >> http://cr.openjdk.java.net/~clanger/webrevs/8156521.1/ >>> >>> I now tried to break lines that are too long and also fixed some other space >> and indentation issues. >>> >>> To incorporate Mark's suggestions regarding plen in enumIPv6Interfaces, I >> consistently renamed it to "prefix" in all places, also in the prefix function for >> BSD. I also reverted back to scanf as int but then cast prefix to short on all >> relevant calls to addif. >>> >>> I verified the build on Linux, AIX, Solaris and MAC and ran a basic >> NetworkInterface test to list interfaces and print addresses and attributes. I >> think I'm done. >>> >>> Chris, would you be so kind to push it when you consider it reviewed? I'm still >> only author. >> >> I will take a final pass over the updated webrev, do some testing, and then >> push it for you. >> >> -Chris. >> >>> Thanks and best regards >>> Christoph >>> >>> >>>> -----Original Message----- >>>> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >>>> Sent: Mittwoch, 11. Mai 2016 12:25 >>>> To: Langer, Christoph >>>> Cc: Alan Bateman ; Dmitry Samersoff >>>> ; net-dev at openjdk.java.net >>>> Subject: Re: RFR(S): 8156521: Minor Fixes and cleanups in >> NetworkInterface.c >>>> >>>> >>>> On 11 May 2016, at 10:21, Langer, Christoph >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> @Chris: As for your points: >>>>> >>>>>> I agree with the replacement of strcpy with strncpy, but I think we should >>>>>> explicitly null terminate in case the src is greater or equal to the dst >> buffer >>>>>> size. This is done elsewhere in this file too, e.g. >>>>>> >>>>>> strncpy(buf, input, sizeof(buf) - 1); >>>>>> buf[sizeof(buf) - 1] = '\0'; >>>>> >>>>> There are 2 different patterns of strncpy usage in this code. One is where >> we >>>> would use strncpy giving the full buffer length and eventually setting the last >>>> byte to 0 to make sure the string is terminated. The other pattern is where a >>>> memset to 0 of the buffer was done before. So I thought it's fine here to give >>>> strncpy "buffersize - 1" as length since per its documentation it would copy >> all >>>> characters up to bufferlen and not terminate with 0 if strlen is >= bufferlen. >>>> That makes sense? >>>> >>>> It does. It was not clear to me that we were calling memset for ALL of these >>>> cases >>>> when I made the comment, but I carefully checked all your changes from >> strcpy >>>> to >>>> strncpy, and they do indeed look fine. >>>> >>>>>>>> Apart from quite a few whitespace changes to clean up the coding, I >> went >>>>>>>> through and replaced all occurences of strcpy with strncpy as this was a >>>>>>>> finding of a code scanner that we used. Also in function >>>>>>>> "enumIPv6Interfaces" for Linux the local variable plen was changed >> from >>>>>>>> int to short. >>>>>> >>>>>> Why was this done for plen specifically, and not scope, or others ? >>>>> >>>>> In struct _netaddr the mask field is defined as short and hence short is >>>> expected by the addif function. So plen should be a short in >> enumIPv6Interfaces >>>> for Linux, too. >>>> >>>> Ok, that's fine. >>>> >>>>> While looking again I see that the BSD function "static int prefix(void *val, >> int >>>> size)" should also rather be a "static short prefix(void *val, int size)". Shall I >>>> update this as well? >>>> >>>> Probably. >>>> >>>>> @Alan: As for the line length: If I get the feedback on those 2 points I'll >>>> prepare a new webrev to shorten some lines. >>>> >>>> That would be great, thanks. >>>> >>>> -Chris. > From chris.hegarty at oracle.com Thu May 12 16:27:03 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 12 May 2016 17:27:03 +0100 Subject: RFR 8016521: InetAddress should not always re-order addresses returned from name service In-Reply-To: <2f153c27-44b3-49fd-9378-0aceedcd8249.maildroid@localhost> References: <5731B29F.8010806@oracle.com> <2f153c27-44b3-49fd-9378-0aceedcd8249.maildroid@localhost> Message-ID: On 10 May 2016, at 20:52, ecki at zusammenkunft.net wrote: > Hello, > > Love it. Yes, this is along the same lines as I was thinking. > Not sure about two things, first of all if there are more test cases (especially assertions) needed and Right. Maybe a new test that, 1) runs in all three modes, and 2) asserts that the order of addressed returned from several different InetAddress getXXX calls, is consistent with what we expect. Though, I?m not sure how to check ?system? other than it must contain the same set of addresses as 'false' or ?true?. I wonder if being able to successfully create a java.io.channels.DatagramChannel.open(StandardProtocolFamily.INET6) is a reliable way to tell if IPv6 is supported. > secondly how to handle the prefer=System case for anyAddr and local. Currently it seems to prefer v4 (since this is the current default) howver i would expect in the system case to either detect the prefered AF or use ipv6 (as of rfc). Returning 127.0.1/0.0.0.0 might actually make the system based address detection unuseable in v6 scenarios. I agree. Specifically you talking about Inet6AddressImpl anyLocalAddress() and loopbackAddress(), right? I think the changes in Inet6AddressImpl need to check: if (InetAddress.preferIPv6Address == PREFER_IPV6_VALUE || InetAddress.preferIPv6Address == PREFER_SYSTEM_VALUE) InetAddressImplFactory already checks for ?isIPv6Supported? when determining which impl to create. If an Inet6AddressImpl is created, then IPv6 is supported on the system, therefore either PREFER_SYSTEM_VALUE or PREFER_IPV6_VALUE should cause anyLocalAddress() and loopbackAddress() to return an Inet6Address. Other minor comments: Inet6AddressImpl.java: can you statically import the int values unix Inet6AddressImpl.c. missing space, ?if(?)? L 445 -Chris. > Gruss > Bernd > -- > http://bernd.eckenfels.net > > -----Original Message----- > From: vyom > To: net-dev > Sent: Di., 10 Mai 2016 12:36 > Subject: RFR 8016521: InetAddress should not always re-order addresses returned from name service > > Hi All, > > Please review the code changes for the below issue. > > Bug : JDK-8016521 : InetAddress should not always re-order > addresses returned from name service > Webrev : > http://cr.openjdk.java.net/~vtewari/8016521/webrev0.0/index.html > > > Thanks, > Vyom > From christoph.langer at sap.com Thu May 12 18:17:39 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 12 May 2016 18:17:39 +0000 Subject: RFR(S): 8156521: Minor Fixes and cleanups in NetworkInterface.c In-Reply-To: <81CF3E8F-FE4E-477E-A661-A58FF316ABF1@oracle.com> References: <18ba30dd5f2444d4834665ec29b1d00b@DEWDFE13DE11.global.corp.sap> <5732E2B7.8010007@oracle.com> <6A9DC12B-3F6B-4FD5-AD12-852885B5176D@oracle.com> <588139064be7405ba3abecef05cb3fb7@DEWDFE13DE11.global.corp.sap> <1732F6B2-AC99-41B5-BCC7-2D164FB20716@oracle.com> <9AC8C5F1-9148-43F3-BEE5-78FDA1169623@oracle.com> <81CF3E8F-FE4E-477E-A661-A58FF316ABF1@oracle.com> Message-ID: <457a6e488d1b4c8ba672f91ca2a309a9@DEWDFE13DE11.global.corp.sap> Looks nice, thanks :) > -----Original Message----- > From: Chris Hegarty [mailto:chris.hegarty at oracle.com] > Sent: Donnerstag, 12. Mai 2016 17:36 > To: Langer, Christoph > Cc: net-dev at openjdk.java.net > Subject: Re: RFR(S): 8156521: Minor Fixes and cleanups in NetworkInterface.c > > Pushed, with a few additional stylistic edits. > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/fe3e1508653e > > On 12 May 2016, at 12:00, Langer, Christoph > wrote: > > > Thanks Chris. > > > > When you finally wrap it up, maybe you want to have a look at one thing > which I didn't dare to clean up. In line 28 you find: > > > > #if defined(_ALLBSD_SOURCE) && defined(__OpenBSD__) > > #include > > #endif > > I omitted this from the current set of cleanups. It can be done later, > if needed. > > -Chris. > > > But will also be included unconditionally for all platforms in line > 34. So maybe this part for OpenBSD could be removed. > > It would change the include order on OpenBSD, of course. As I don't have an > OpenBSD build environment I decided not to touch this but you could remove it > if you have more confidence... > > > > Best regards > > Christoph > > > > > >> -----Original Message----- > >> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] > >> Sent: Donnerstag, 12. Mai 2016 12:43 > >> To: Langer, Christoph > >> Cc: Alan Bateman ; Dmitry Samersoff > >> ; Mark Sheppard > >> ; net-dev at openjdk.java.net > >> Subject: Re: RFR(S): 8156521: Minor Fixes and cleanups in > NetworkInterface.c > >> > >> On 11 May 2016, at 22:27, Langer, Christoph > >> wrote: > >> > >>> Hi again, > >>> > >>> I'm done with the new version: > >> http://cr.openjdk.java.net/~clanger/webrevs/8156521.1/ > >>> > >>> I now tried to break lines that are too long and also fixed some other space > >> and indentation issues. > >>> > >>> To incorporate Mark's suggestions regarding plen in enumIPv6Interfaces, I > >> consistently renamed it to "prefix" in all places, also in the prefix function > for > >> BSD. I also reverted back to scanf as int but then cast prefix to short on all > >> relevant calls to addif. > >>> > >>> I verified the build on Linux, AIX, Solaris and MAC and ran a basic > >> NetworkInterface test to list interfaces and print addresses and attributes. I > >> think I'm done. > >>> > >>> Chris, would you be so kind to push it when you consider it reviewed? I'm > still > >> only author. > >> > >> I will take a final pass over the updated webrev, do some testing, and then > >> push it for you. > >> > >> -Chris. > >> > >>> Thanks and best regards > >>> Christoph > >>> > >>> > >>>> -----Original Message----- > >>>> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] > >>>> Sent: Mittwoch, 11. Mai 2016 12:25 > >>>> To: Langer, Christoph > >>>> Cc: Alan Bateman ; Dmitry Samersoff > >>>> ; net-dev at openjdk.java.net > >>>> Subject: Re: RFR(S): 8156521: Minor Fixes and cleanups in > >> NetworkInterface.c > >>>> > >>>> > >>>> On 11 May 2016, at 10:21, Langer, Christoph > > >>>> wrote: > >>>> > >>>>> Hi, > >>>>> > >>>>> @Chris: As for your points: > >>>>> > >>>>>> I agree with the replacement of strcpy with strncpy, but I think we > should > >>>>>> explicitly null terminate in case the src is greater or equal to the dst > >> buffer > >>>>>> size. This is done elsewhere in this file too, e.g. > >>>>>> > >>>>>> strncpy(buf, input, sizeof(buf) - 1); > >>>>>> buf[sizeof(buf) - 1] = '\0'; > >>>>> > >>>>> There are 2 different patterns of strncpy usage in this code. One is > where > >> we > >>>> would use strncpy giving the full buffer length and eventually setting the > last > >>>> byte to 0 to make sure the string is terminated. The other pattern is > where a > >>>> memset to 0 of the buffer was done before. So I thought it's fine here to > give > >>>> strncpy "buffersize - 1" as length since per its documentation it would > copy > >> all > >>>> characters up to bufferlen and not terminate with 0 if strlen is >= > bufferlen. > >>>> That makes sense? > >>>> > >>>> It does. It was not clear to me that we were calling memset for ALL of > these > >>>> cases > >>>> when I made the comment, but I carefully checked all your changes from > >> strcpy > >>>> to > >>>> strncpy, and they do indeed look fine. > >>>> > >>>>>>>> Apart from quite a few whitespace changes to clean up the coding, I > >> went > >>>>>>>> through and replaced all occurences of strcpy with strncpy as this > was a > >>>>>>>> finding of a code scanner that we used. Also in function > >>>>>>>> "enumIPv6Interfaces" for Linux the local variable plen was changed > >> from > >>>>>>>> int to short. > >>>>>> > >>>>>> Why was this done for plen specifically, and not scope, or others ? > >>>>> > >>>>> In struct _netaddr the mask field is defined as short and hence short is > >>>> expected by the addif function. So plen should be a short in > >> enumIPv6Interfaces > >>>> for Linux, too. > >>>> > >>>> Ok, that's fine. > >>>> > >>>>> While looking again I see that the BSD function "static int prefix(void > *val, > >> int > >>>> size)" should also rather be a "static short prefix(void *val, int size)". Shall > I > >>>> update this as well? > >>>> > >>>> Probably. > >>>> > >>>>> @Alan: As for the line length: If I get the feedback on those 2 points I'll > >>>> prepare a new webrev to shorten some lines. > >>>> > >>>> That would be great, thanks. > >>>> > >>>> -Chris. > > From artem.smotrakov at oracle.com Thu May 12 21:10:09 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Thu, 12 May 2016 14:10:09 -0700 Subject: [9] RFR: 8156710: HttpTimeoutException should be thrown if server doesn't respond Message-ID: <5734F131.70802@oracle.com> Hello, Please review this for 9. Stream.getResponse() method can hang because it calls join() method without any timeout. It would be better if it took into account a timeout value specified for a connection, and threw HttpTimeoutException if timeout was reached. The patch updates Stream.getResponse() method to use CompletableFuture.get() method with timeout if a timeout value was specified for HTTPRequest. Timeout.java test starts a TLS server which just reads incoming data, but doesn't reply anything. The client sets a timeout with HTTPRequestBuilder.Builder.timeout() method, and then expects HttpTimeoutException. The test initializes JSSE with standard way by system properties. RSA keys are located in keystore.p12 which can be re-used by other tests. The keys were created by the following command: keytool -genkey -alias rsa2048keypair -keystore keystore.p12 -storepass password -keypass password -validity 3650 -keysize 2048 -dname "CN=Test RSA 2048 key" Bug: https://bugs.openjdk.java.net/browse/JDK-8156710 Webrev: http://cr.openjdk.java.net/~asmotrak/8156710/webrev.01/ Artem From vyom.tewari at oracle.com Fri May 13 07:23:44 2016 From: vyom.tewari at oracle.com (vyom) Date: Fri, 13 May 2016 12:53:44 +0530 Subject: RFR 8016521: InetAddress should not always re-order addresses returned from name service In-Reply-To: References: <5731B29F.8010806@oracle.com> <2f153c27-44b3-49fd-9378-0aceedcd8249.maildroid@localhost> Message-ID: <57358100.2020906@oracle.com> Hi, Please find the updated webrev(http://cr.openjdk.java.net/~vtewari/8016521/webrev0.1/index.html ), i incorporated the review comments. Thanks, Vyom On Thursday 12 May 2016 09:57 PM, Chris Hegarty wrote: > On 10 May 2016, at 20:52, ecki at zusammenkunft.net wrote: > >> Hello, >> >> Love it. > Yes, this is along the same lines as I was thinking. > >> Not sure about two things, first of all if there are more test cases (especially assertions) needed and > Right. Maybe a new test that, 1) runs in all three modes, and 2) asserts > that the order of addressed returned from several different InetAddress > getXXX calls, is consistent with what we expect. Though, I?m not sure how > to check ?system? other than it must contain the same set of addresses > as 'false' or ?true?. > > I wonder if being able to successfully create a > java.io.channels.DatagramChannel.open(StandardProtocolFamily.INET6) > is a reliable way to tell if IPv6 is supported. > >> secondly how to handle the prefer=System case for anyAddr and local. Currently it seems to prefer v4 (since this is the current default) howver i would expect in the system case to either detect the prefered AF or use ipv6 (as of rfc). Returning 127.0.1/0.0.0.0 might actually make the system based address detection unuseable in v6 scenarios. > I agree. Specifically you talking about Inet6AddressImpl > anyLocalAddress() and loopbackAddress(), right? > I think the changes in Inet6AddressImpl need to check: > > if (InetAddress.preferIPv6Address == PREFER_IPV6_VALUE || > InetAddress.preferIPv6Address == PREFER_SYSTEM_VALUE) > > InetAddressImplFactory already checks for ?isIPv6Supported? when > determining which impl to create. If an Inet6AddressImpl is created, > then IPv6 is supported on the system, therefore either > PREFER_SYSTEM_VALUE or PREFER_IPV6_VALUE should > cause anyLocalAddress() and loopbackAddress() to return an > Inet6Address. > > > Other minor comments: > Inet6AddressImpl.java: can you statically import the int values > unix Inet6AddressImpl.c. missing space, ?if(?)? L 445 > > -Chris. > >> Gruss >> Bernd >> -- >> http://bernd.eckenfels.net >> >> -----Original Message----- >> From: vyom >> To: net-dev >> Sent: Di., 10 Mai 2016 12:36 >> Subject: RFR 8016521: InetAddress should not always re-order addresses returned from name service >> >> Hi All, >> >> Please review the code changes for the below issue. >> >> Bug : JDK-8016521 : InetAddress should not always re-order >> addresses returned from name service >> Webrev : >> http://cr.openjdk.java.net/~vtewari/8016521/webrev0.0/index.html >> >> >> Thanks, >> Vyom >> From michael.x.mcmahon at oracle.com Fri May 13 10:03:24 2016 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Fri, 13 May 2016 11:03:24 +0100 Subject: [9] RFR: 8156710: HttpTimeoutException should be thrown if server doesn't respond In-Reply-To: <5734F131.70802@oracle.com> References: <5734F131.70802@oracle.com> Message-ID: <5735A66C.1000002@oracle.com> Artem, Thanks for doing this. Eventually, the fix will have to be updated to reset the stream, but all the required functionality for that isn't there yet. Also, I think a test which uses the test http2 server will be needed. But, for now, the fix looks fine. - Michael. On 12/05/16 22:10, Artem Smotrakov wrote: > Hello, > > Please review this for 9. > > Stream.getResponse() method can hang because it calls join() method > without any timeout. It would be better if it took into account a > timeout value specified for a connection, and threw > HttpTimeoutException if timeout was reached. > > The patch updates Stream.getResponse() method to use > CompletableFuture.get() method with timeout if a timeout value was > specified for HTTPRequest. > > Timeout.java test starts a TLS server which just reads incoming data, > but doesn't reply anything. The client sets a timeout with > HTTPRequestBuilder.Builder.timeout() method, and then expects > HttpTimeoutException. > > The test initializes JSSE with standard way by system properties. RSA > keys are located in keystore.p12 which can be re-used by other tests. > The keys were created by the following command: > > keytool -genkey -alias rsa2048keypair -keystore keystore.p12 > -storepass password -keypass password -validity 3650 -keysize 2048 > -dname "CN=Test RSA 2048 key" > > Bug: https://bugs.openjdk.java.net/browse/JDK-8156710 > Webrev: http://cr.openjdk.java.net/~asmotrak/8156710/webrev.01/ > > Artem From chris.hegarty at oracle.com Fri May 13 13:03:13 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 13 May 2016 14:03:13 +0100 Subject: RFR 8016521: InetAddress should not always re-order addresses returned from name service In-Reply-To: <57358100.2020906@oracle.com> References: <5731B29F.8010806@oracle.com> <2f153c27-44b3-49fd-9378-0aceedcd8249.maildroid@localhost> <57358100.2020906@oracle.com> Message-ID: <5735D091.6080903@oracle.com> Vyom, On 13/05/16 08:23, vyom wrote: > Hi, > > Please find the updated > webrev(http://cr.openjdk.java.net/~vtewari/8016521/webrev0.1/index.html > ), i > incorporated the review comments. This addresses my comments regarding the code. I'm still not sure what, if anything, we can do in the area of testing, but maybe that could be done as a follow up. One final comment, that I missed earlier. I think preferIPv6Address can be made final, if you remove the '-1' initializer. -Chris. > Thanks, > Vyom > > > On Thursday 12 May 2016 09:57 PM, Chris Hegarty wrote: >> On 10 May 2016, at 20:52, ecki at zusammenkunft.net wrote: >> >>> Hello, >>> >>> Love it. >> Yes, this is along the same lines as I was thinking. >> >>> Not sure about two things, first of all if there are more test cases >>> (especially assertions) needed and >> Right. Maybe a new test that, 1) runs in all three modes, and 2) asserts >> that the order of addressed returned from several different InetAddress >> getXXX calls, is consistent with what we expect. Though, I?m not sure how >> to check ?system? other than it must contain the same set of addresses >> as 'false' or ?true?. >> >> I wonder if being able to successfully create a >> java.io.channels.DatagramChannel.open(StandardProtocolFamily.INET6) >> is a reliable way to tell if IPv6 is supported. >> >>> secondly how to handle the prefer=System case for anyAddr and local. >>> Currently it seems to prefer v4 (since this is the current default) >>> howver i would expect in the system case to either detect the >>> prefered AF or use ipv6 (as of rfc). Returning 127.0.1/0.0.0.0 might >>> actually make the system based address detection unuseable in v6 >>> scenarios. >> I agree. Specifically you talking about Inet6AddressImpl >> anyLocalAddress() and loopbackAddress(), right? >> I think the changes in Inet6AddressImpl need to check: >> >> if (InetAddress.preferIPv6Address == PREFER_IPV6_VALUE || >> InetAddress.preferIPv6Address == PREFER_SYSTEM_VALUE) >> >> InetAddressImplFactory already checks for ?isIPv6Supported? when >> determining which impl to create. If an Inet6AddressImpl is created, >> then IPv6 is supported on the system, therefore either >> PREFER_SYSTEM_VALUE or PREFER_IPV6_VALUE should >> cause anyLocalAddress() and loopbackAddress() to return an >> Inet6Address. >> >> >> Other minor comments: >> Inet6AddressImpl.java: can you statically import the int values >> unix Inet6AddressImpl.c. missing space, ?if(?)? L 445 >> >> -Chris. >> >>> Gruss >>> Bernd >>> -- >>> http://bernd.eckenfels.net >>> >>> -----Original Message----- >>> From: vyom >>> To: net-dev >>> Sent: Di., 10 Mai 2016 12:36 >>> Subject: RFR 8016521: InetAddress should not always re-order >>> addresses returned from name service >>> >>> Hi All, >>> >>> Please review the code changes for the below issue. >>> >>> Bug : JDK-8016521 : InetAddress should not always re-order >>> addresses returned from name service >>> Webrev : >>> http://cr.openjdk.java.net/~vtewari/8016521/webrev0.0/index.html >>> >>> >>> Thanks, >>> Vyom >>> > From simone.bordet at gmail.com Sat May 14 13:53:50 2016 From: simone.bordet at gmail.com (Simone Bordet) Date: Sat, 14 May 2016 15:53:50 +0200 Subject: RFR JDK-8087113: Websocket API and implementation In-Reply-To: References: Message-ID: Hi, On Tue, May 10, 2016 at 2:03 PM, Pavel Rappo wrote: > Hi Simone, > >> On 4 Apr 2016, at 20:07, Simone Bordet wrote: >> >> In my experience, once you get rid of exception throwing in async API >> everything becomes much simpler, especially "deep" exceptions related >> to invalid implementation internal states. > > Am I right saying that you propose that all exceptions (incl. NullPointerException, > IllegalArgumentException, etc.) to be relayed through the CompletionStage rather > than thrown in-place? I guess the point is to answer the question of what semantic you want to have when calling a WebSocket method that returns a CF. CF wsCF = ws.sendBinary(...); wsCF.exceptionally(failure -> sendImportantEmail(failure)); Is an application required to implement both CF.exceptionally(fn) *and* surround ws.sendBinary() with a try/catch in *all* call sites ? My take is that because there are certain errors that cannot be detected early (or in the same thread) and therefore there must be a mechanism to report errors via the CF, then perhaps it would be best to only use that mechanism. By performing the sanity checks immediately, and notifying (synchronously) the CF rather than throwing, you would maintain the stack trace that led to the wrong call, so you would be able to look at the stack to know what was the call chain that passed, for example, a null ByteBuffer to sendBinary(...). Now, the question of the immediate sanity checks can be debatable and I don't have a strong opinion: I can live with it if you decide to throw. However, *any* exception that happen later in the processing, possibly after a thread dispatch, *must* be reported as a CF failure. You cannot let later IllegalStateExceptions or such to unwind the thread stack without notifying the CF. >> I see that the WebSocket implementation throws InternalError. >> This is typically used for *JVM* failures, not application failures. >> Applications are used to catch Exception, not Throwable, so >> InternalError may not be handled well. >> I suggest to not use Error or subclasses for application or >> implementation failures, but Exception or subclasses instead. > > You're right. I knew that well when decided to use it. Look through the JDK code > and you'll find that InternalError is used for cases like this very often. It's > a de facto standard. In almost all the places where InternalError is thrown in the WebSocket implementation, you can throw an IllegalStateException or other runtime exceptions. Anyway, your call. -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From michael.x.mcmahon at oracle.com Mon May 16 11:07:22 2016 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 16 May 2016 12:07:22 +0100 Subject: RFR 8156825: java/net/httpclient/BasicWebSocketAPITest.java failed with "java.lang.AssertionError" Message-ID: <5739A9EA.5030807@oracle.com> Could I get the following change reviewed please? There are three small changes 1) enhancements to RawChannel API used by websocket implementation 2) fix the test case problem where channel might not be in non-blocking mode (also remove erroneous asssertion check) 3) Remove (unused) and unintentionally public HttpHeaders1 type http://cr.openjdk.java.net/~michaelm/8156825/webrev.1/ Thanks, Michael From pavel.rappo at oracle.com Mon May 16 13:13:06 2016 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Mon, 16 May 2016 14:13:06 +0100 Subject: RFR 8156825: java/net/httpclient/BasicWebSocketAPITest.java failed with "java.lang.AssertionError" In-Reply-To: <5739A9EA.5030807@oracle.com> References: <5739A9EA.5030807@oracle.com> Message-ID: This looks good, Michael. Thanks. > On 16 May 2016, at 12:07, Michael McMahon wrote: > > Could I get the following change reviewed please? There are three small changes > > 1) enhancements to RawChannel API used by websocket implementation > > 2) fix the test case problem where channel might not be in non-blocking mode > (also remove erroneous asssertion check) > > 3) Remove (unused) and unintentionally public HttpHeaders1 type > > http://cr.openjdk.java.net/~michaelm/8156825/webrev.1/ > > Thanks, > Michael From Roger.Riggs at Oracle.com Mon May 16 14:11:27 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 16 May 2016 10:11:27 -0400 Subject: RFR 8156825: java/net/httpclient/BasicWebSocketAPITest.java failed with "java.lang.AssertionError" In-Reply-To: <5739A9EA.5030807@oracle.com> References: <5739A9EA.5030807@oracle.com> Message-ID: <3660923c-cd3b-619f-f6dd-10f2161085d3@Oracle.com> Hi Michael, +1 HttpClientImpl.java: Unless a large number of classes are needed, individual imports are preferred. (Maybe the IDE did that for you, in which the IDE should be reconfigured.) Roger On 5/16/2016 7:07 AM, Michael McMahon wrote: > Could I get the following change reviewed please? There are three > small changes > > 1) enhancements to RawChannel API used by websocket implementation > > 2) fix the test case problem where channel might not be in > non-blocking mode > (also remove erroneous asssertion check) > > 3) Remove (unused) and unintentionally public HttpHeaders1 type > > http://cr.openjdk.java.net/~michaelm/8156825/webrev.1/ > > Thanks, > Michael From michael.x.mcmahon at oracle.com Mon May 16 14:09:41 2016 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 16 May 2016 15:09:41 +0100 Subject: RFR 8156825: java/net/httpclient/BasicWebSocketAPITest.java failed with "java.lang.AssertionError" In-Reply-To: <3660923c-cd3b-619f-f6dd-10f2161085d3@Oracle.com> References: <5739A9EA.5030807@oracle.com> <3660923c-cd3b-619f-f6dd-10f2161085d3@Oracle.com> Message-ID: <5739D4A5.8030109@oracle.com> Thanks Roger. What would the consensus be on what 'a large number' is? - Michael On 16/05/16 15:11, Roger Riggs wrote: > Hi Michael, > > +1 > > HttpClientImpl.java: Unless a large number of classes are needed, > individual imports are preferred. > > (Maybe the IDE did that for you, in which the IDE should be > reconfigured.) > > Roger > > > On 5/16/2016 7:07 AM, Michael McMahon wrote: >> Could I get the following change reviewed please? There are three >> small changes >> >> 1) enhancements to RawChannel API used by websocket implementation >> >> 2) fix the test case problem where channel might not be in >> non-blocking mode >> (also remove erroneous asssertion check) >> >> 3) Remove (unused) and unintentionally public HttpHeaders1 type >> >> http://cr.openjdk.java.net/~michaelm/8156825/webrev.1/ >> >> Thanks, >> Michael > From Roger.Riggs at Oracle.com Mon May 16 14:21:12 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 16 May 2016 10:21:12 -0400 Subject: RFR 8156825: java/net/httpclient/BasicWebSocketAPITest.java failed with "java.lang.AssertionError" In-Reply-To: <5739D4A5.8030109@oracle.com> References: <5739A9EA.5030807@oracle.com> <3660923c-cd3b-619f-f6dd-10f2161085d3@Oracle.com> <5739D4A5.8030109@oracle.com> Message-ID: Hi, Large: not a fixed number; but enough that if you glance at them and do not know how many. Or: So many that anyone would say they tried to read it and lost track of how many. TL;DR I would say 8-10. In immutable collections; 10 was the number for the threshold in the new List constructors. YMMYV Roger On 5/16/2016 10:09 AM, Michael McMahon wrote: > Thanks Roger. What would the consensus be on what 'a large number' is? > > - Michael > > On 16/05/16 15:11, Roger Riggs wrote: >> Hi Michael, >> >> +1 >> >> HttpClientImpl.java: Unless a large number of classes are needed, >> individual imports are preferred. >> >> (Maybe the IDE did that for you, in which the IDE should be >> reconfigured.) >> >> Roger >> >> >> On 5/16/2016 7:07 AM, Michael McMahon wrote: >>> Could I get the following change reviewed please? There are three >>> small changes >>> >>> 1) enhancements to RawChannel API used by websocket implementation >>> >>> 2) fix the test case problem where channel might not be in >>> non-blocking mode >>> (also remove erroneous asssertion check) >>> >>> 3) Remove (unused) and unintentionally public HttpHeaders1 type >>> >>> http://cr.openjdk.java.net/~michaelm/8156825/webrev.1/ >>> >>> Thanks, >>> Michael >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dalibor.topic at oracle.com Mon May 16 15:05:55 2016 From: dalibor.topic at oracle.com (dalibor topic) Date: Mon, 16 May 2016 17:05:55 +0200 Subject: Reminder about reported problem in NetworkInterface.c In-Reply-To: References: <57345B85.6040608@oracle.com> Message-ID: <5ce5e50a-5e2f-f9f3-7780-421658d8780f@oracle.com> On 12.05.2016 13:18, Ivan St. Ivanov wrote: > Hello Alan, > > If that is the showstopper for moving this change forward, Quoting from the very first step of the OpenJDK contribution guide at http://openjdk.java.net/contribute/ "If you haven't yet signed the Oracle Contributor Agreement (OCA) then please do so, scan it and e-mail the result to oracle-ca_us(at)oracle.com." > Doychin is > part of the Bulgarian JUG. Which has signed the OCA. That's not correct. The Bulgarian JUG does not have an OCA on file, as you can see at http://www.oracle.com/technetwork/community/oca-486395.html#b . You may be confusing the OCA with something else. At this time, there are no JUGs with an OCA. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From vyom.tewari at oracle.com Tue May 17 09:48:50 2016 From: vyom.tewari at oracle.com (vyom) Date: Tue, 17 May 2016 15:18:50 +0530 Subject: RFR 8016521: InetAddress should not always re-order addresses returned from name service In-Reply-To: <5735D091.6080903@oracle.com> References: <5731B29F.8010806@oracle.com> <2f153c27-44b3-49fd-9378-0aceedcd8249.maildroid@localhost> <57358100.2020906@oracle.com> <5735D091.6080903@oracle.com> Message-ID: <573AE902.400@oracle.com> Hi Chris, Please find the updated webrev(http://cr.openjdk.java.net/~vtewari/8016521/webrev0.2/index.html ). Thanks, Vyom On Friday 13 May 2016 06:33 PM, Chris Hegarty wrote: > Vyom, > > On 13/05/16 08:23, vyom wrote: >> Hi, >> >> Please find the updated >> webrev(http://cr.openjdk.java.net/~vtewari/8016521/webrev0.1/index.html >> ), i >> incorporated the review comments. > > This addresses my comments regarding the code. I'm still not > sure what, if anything, we can do in the area of testing, but > maybe that could be done as a follow up. > > One final comment, that I missed earlier. I think > preferIPv6Address can be made final, if you remove the '-1' > initializer. > > -Chris. > >> Thanks, >> Vyom >> >> >> On Thursday 12 May 2016 09:57 PM, Chris Hegarty wrote: >>> On 10 May 2016, at 20:52, ecki at zusammenkunft.net wrote: >>> >>>> Hello, >>>> >>>> Love it. >>> Yes, this is along the same lines as I was thinking. >>> >>>> Not sure about two things, first of all if there are more test cases >>>> (especially assertions) needed and >>> Right. Maybe a new test that, 1) runs in all three modes, and 2) >>> asserts >>> that the order of addressed returned from several different InetAddress >>> getXXX calls, is consistent with what we expect. Though, I?m not >>> sure how >>> to check ?system? other than it must contain the same set of addresses >>> as 'false' or ?true?. >>> >>> I wonder if being able to successfully create a >>> java.io.channels.DatagramChannel.open(StandardProtocolFamily.INET6) >>> is a reliable way to tell if IPv6 is supported. >>> >>>> secondly how to handle the prefer=System case for anyAddr and local. >>>> Currently it seems to prefer v4 (since this is the current default) >>>> howver i would expect in the system case to either detect the >>>> prefered AF or use ipv6 (as of rfc). Returning 127.0.1/0.0.0.0 might >>>> actually make the system based address detection unuseable in v6 >>>> scenarios. >>> I agree. Specifically you talking about Inet6AddressImpl >>> anyLocalAddress() and loopbackAddress(), right? >>> I think the changes in Inet6AddressImpl need to check: >>> >>> if (InetAddress.preferIPv6Address == PREFER_IPV6_VALUE || >>> InetAddress.preferIPv6Address == PREFER_SYSTEM_VALUE) >>> >>> InetAddressImplFactory already checks for ?isIPv6Supported? when >>> determining which impl to create. If an Inet6AddressImpl is created, >>> then IPv6 is supported on the system, therefore either >>> PREFER_SYSTEM_VALUE or PREFER_IPV6_VALUE should >>> cause anyLocalAddress() and loopbackAddress() to return an >>> Inet6Address. >>> >>> >>> Other minor comments: >>> Inet6AddressImpl.java: can you statically import the int values >>> unix Inet6AddressImpl.c. missing space, ?if(?)? L 445 >>> >>> -Chris. >>> >>>> Gruss >>>> Bernd >>>> -- >>>> http://bernd.eckenfels.net >>>> >>>> -----Original Message----- >>>> From: vyom >>>> To: net-dev >>>> Sent: Di., 10 Mai 2016 12:36 >>>> Subject: RFR 8016521: InetAddress should not always re-order >>>> addresses returned from name service >>>> >>>> Hi All, >>>> >>>> Please review the code changes for the below issue. >>>> >>>> Bug : JDK-8016521 : InetAddress should not always re-order >>>> addresses returned from name service >>>> Webrev : >>>> http://cr.openjdk.java.net/~vtewari/8016521/webrev0.0/index.html >>>> >>>> >>>> Thanks, >>>> Vyom >>>> >> From chris.hegarty at oracle.com Tue May 17 11:34:24 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 17 May 2016 12:34:24 +0100 Subject: RFR 8016521: InetAddress should not always re-order addresses returned from name service In-Reply-To: <573AE902.400@oracle.com> References: <5731B29F.8010806@oracle.com> <2f153c27-44b3-49fd-9378-0aceedcd8249.maildroid@localhost> <57358100.2020906@oracle.com> <5735D091.6080903@oracle.com> <573AE902.400@oracle.com> Message-ID: <700EF449-4840-416D-8390-5B44B41C8A1F@oracle.com> On 17 May 2016, at 10:48, vyom wrote: > Hi Chris, > > Please find the updated webrev(http://cr.openjdk.java.net/~vtewari/8016521/webrev0.2/index.html ). This looks good Vyom. Thanks. One additional change is needed. Apologies, I forgot that the specification of java.net.preferIPv6Addresses was in the source tree and not in the guides. We will need to update this, something similar to... diff --git a/src/java.base/share/classes/java/net/doc-files/net-properties.html b/src/java.base/share/classes/java/net/doc-files/net-properties.html --- a/src/java.base/share/classes/java/net/doc-files/net-properties.html +++ b/src/java.base/share/classes/java/net/doc-files/net-properties.html @@ -58,7 +58,8 @@ applications that depend on the representation of an IPv4 address (e.g. 192.168.1.1). This property can be set to true to change that preference and use IPv6 addresses over IPv4 ones where - possible.

+ possible, or system to preserve the order of the addresses as + returned by the operating system.

Both of these properties are checked only once, at startup.

If you agree, can you fold it into your patch, and generate a changeset. -Chris. > Thanks, > Vyom > > > On Friday 13 May 2016 06:33 PM, Chris Hegarty wrote: >> Vyom, >> >> On 13/05/16 08:23, vyom wrote: >>> Hi, >>> >>> Please find the updated >>> webrev(http://cr.openjdk.java.net/~vtewari/8016521/webrev0.1/index.html >>> ), i >>> incorporated the review comments. >> >> This addresses my comments regarding the code. I'm still not >> sure what, if anything, we can do in the area of testing, but >> maybe that could be done as a follow up. >> >> One final comment, that I missed earlier. I think >> preferIPv6Address can be made final, if you remove the '-1' >> initializer. >> >> -Chris. >> >>> Thanks, >>> Vyom >>> >>> >>> On Thursday 12 May 2016 09:57 PM, Chris Hegarty wrote: >>>> On 10 May 2016, at 20:52, ecki at zusammenkunft.net wrote: >>>> >>>>> Hello, >>>>> >>>>> Love it. >>>> Yes, this is along the same lines as I was thinking. >>>> >>>>> Not sure about two things, first of all if there are more test cases >>>>> (especially assertions) needed and >>>> Right. Maybe a new test that, 1) runs in all three modes, and 2) asserts >>>> that the order of addressed returned from several different InetAddress >>>> getXXX calls, is consistent with what we expect. Though, I?m not sure how >>>> to check ?system? other than it must contain the same set of addresses >>>> as 'false' or ?true?. >>>> >>>> I wonder if being able to successfully create a >>>> java.io.channels.DatagramChannel.open(StandardProtocolFamily.INET6) >>>> is a reliable way to tell if IPv6 is supported. >>>> >>>>> secondly how to handle the prefer=System case for anyAddr and local. >>>>> Currently it seems to prefer v4 (since this is the current default) >>>>> howver i would expect in the system case to either detect the >>>>> prefered AF or use ipv6 (as of rfc). Returning 127.0.1/0.0.0.0 might >>>>> actually make the system based address detection unuseable in v6 >>>>> scenarios. >>>> I agree. Specifically you talking about Inet6AddressImpl >>>> anyLocalAddress() and loopbackAddress(), right? >>>> I think the changes in Inet6AddressImpl need to check: >>>> >>>> if (InetAddress.preferIPv6Address == PREFER_IPV6_VALUE || >>>> InetAddress.preferIPv6Address == PREFER_SYSTEM_VALUE) >>>> >>>> InetAddressImplFactory already checks for ?isIPv6Supported? when >>>> determining which impl to create. If an Inet6AddressImpl is created, >>>> then IPv6 is supported on the system, therefore either >>>> PREFER_SYSTEM_VALUE or PREFER_IPV6_VALUE should >>>> cause anyLocalAddress() and loopbackAddress() to return an >>>> Inet6Address. >>>> >>>> >>>> Other minor comments: >>>> Inet6AddressImpl.java: can you statically import the int values >>>> unix Inet6AddressImpl.c. missing space, ?if(?)? L 445 >>>> >>>> -Chris. >>>> >>>>> Gruss >>>>> Bernd >>>>> -- >>>>> http://bernd.eckenfels.net >>>>> >>>>> -----Original Message----- >>>>> From: vyom >>>>> To: net-dev >>>>> Sent: Di., 10 Mai 2016 12:36 >>>>> Subject: RFR 8016521: InetAddress should not always re-order >>>>> addresses returned from name service >>>>> >>>>> Hi All, >>>>> >>>>> Please review the code changes for the below issue. >>>>> >>>>> Bug : JDK-8016521 : InetAddress should not always re-order >>>>> addresses returned from name service >>>>> Webrev : >>>>> http://cr.openjdk.java.net/~vtewari/8016521/webrev0.0/index.html >>>>> >>>>> >>>>> Thanks, >>>>> Vyom >>>>> >>> > From vyom.tewari at oracle.com Tue May 17 13:36:35 2016 From: vyom.tewari at oracle.com (vyom) Date: Tue, 17 May 2016 19:06:35 +0530 Subject: RFR 8016521: InetAddress should not always re-order addresses returned from name service In-Reply-To: <700EF449-4840-416D-8390-5B44B41C8A1F@oracle.com> References: <5731B29F.8010806@oracle.com> <2f153c27-44b3-49fd-9378-0aceedcd8249.maildroid@localhost> <57358100.2020906@oracle.com> <5735D091.6080903@oracle.com> <573AE902.400@oracle.com> <700EF449-4840-416D-8390-5B44B41C8A1F@oracle.com> Message-ID: <573B1E63.2000008@oracle.com> Hi Chris, Please find the updated webrev(http://cr.openjdk.java.net/~vtewari/8016521/webrev0.3/index.html ). i have did the changes as you suggested. Thanks, Vyom On Tuesday 17 May 2016 05:04 PM, Chris Hegarty wrote: > On 17 May 2016, at 10:48, vyom wrote: > >> Hi Chris, >> >> Please find the updated webrev(http://cr.openjdk.java.net/~vtewari/8016521/webrev0.2/index.html ). > This looks good Vyom. Thanks. > > One additional change is needed. Apologies, I forgot that the specification > of java.net.preferIPv6Addresses was in the source tree and not in the > guides. We will need to update this, something similar to... > > diff --git a/src/java.base/share/classes/java/net/doc-files/net-properties.html b/src/java.base/share/classes/java/net/doc-files/net-properties.html > --- a/src/java.base/share/classes/java/net/doc-files/net-properties.html > +++ b/src/java.base/share/classes/java/net/doc-files/net-properties.html > @@ -58,7 +58,8 @@ > applications that depend on the representation of an IPv4 address > (e.g. 192.168.1.1). This property can be set to true to > change that preference and use IPv6 addresses over IPv4 ones where > - possible.

> + possible, or system to preserve the order of the addresses as > + returned by the operating system.

> >

Both of these properties are checked only once, at startup.

> > > If you agree, can you fold it into your patch, and generate a changeset. > > -Chris. > >> Thanks, >> Vyom >> >> >> On Friday 13 May 2016 06:33 PM, Chris Hegarty wrote: >>> Vyom, >>> >>> On 13/05/16 08:23, vyom wrote: >>>> Hi, >>>> >>>> Please find the updated >>>> webrev(http://cr.openjdk.java.net/~vtewari/8016521/webrev0.1/index.html >>>> ), i >>>> incorporated the review comments. >>> This addresses my comments regarding the code. I'm still not >>> sure what, if anything, we can do in the area of testing, but >>> maybe that could be done as a follow up. >>> >>> One final comment, that I missed earlier. I think >>> preferIPv6Address can be made final, if you remove the '-1' >>> initializer. >>> >>> -Chris. >>> >>>> Thanks, >>>> Vyom >>>> >>>> >>>> On Thursday 12 May 2016 09:57 PM, Chris Hegarty wrote: >>>>> On 10 May 2016, at 20:52, ecki at zusammenkunft.net wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> Love it. >>>>> Yes, this is along the same lines as I was thinking. >>>>> >>>>>> Not sure about two things, first of all if there are more test cases >>>>>> (especially assertions) needed and >>>>> Right. Maybe a new test that, 1) runs in all three modes, and 2) asserts >>>>> that the order of addressed returned from several different InetAddress >>>>> getXXX calls, is consistent with what we expect. Though, I?m not sure how >>>>> to check ?system? other than it must contain the same set of addresses >>>>> as 'false' or ?true?. >>>>> >>>>> I wonder if being able to successfully create a >>>>> java.io.channels.DatagramChannel.open(StandardProtocolFamily.INET6) >>>>> is a reliable way to tell if IPv6 is supported. >>>>> >>>>>> secondly how to handle the prefer=System case for anyAddr and local. >>>>>> Currently it seems to prefer v4 (since this is the current default) >>>>>> howver i would expect in the system case to either detect the >>>>>> prefered AF or use ipv6 (as of rfc). Returning 127.0.1/0.0.0.0 might >>>>>> actually make the system based address detection unuseable in v6 >>>>>> scenarios. >>>>> I agree. Specifically you talking about Inet6AddressImpl >>>>> anyLocalAddress() and loopbackAddress(), right? >>>>> I think the changes in Inet6AddressImpl need to check: >>>>> >>>>> if (InetAddress.preferIPv6Address == PREFER_IPV6_VALUE || >>>>> InetAddress.preferIPv6Address == PREFER_SYSTEM_VALUE) >>>>> >>>>> InetAddressImplFactory already checks for ?isIPv6Supported? when >>>>> determining which impl to create. If an Inet6AddressImpl is created, >>>>> then IPv6 is supported on the system, therefore either >>>>> PREFER_SYSTEM_VALUE or PREFER_IPV6_VALUE should >>>>> cause anyLocalAddress() and loopbackAddress() to return an >>>>> Inet6Address. >>>>> >>>>> >>>>> Other minor comments: >>>>> Inet6AddressImpl.java: can you statically import the int values >>>>> unix Inet6AddressImpl.c. missing space, ?if(?)? L 445 >>>>> >>>>> -Chris. >>>>> >>>>>> Gruss >>>>>> Bernd >>>>>> -- >>>>>> http://bernd.eckenfels.net >>>>>> >>>>>> -----Original Message----- >>>>>> From: vyom >>>>>> To: net-dev >>>>>> Sent: Di., 10 Mai 2016 12:36 >>>>>> Subject: RFR 8016521: InetAddress should not always re-order >>>>>> addresses returned from name service >>>>>> >>>>>> Hi All, >>>>>> >>>>>> Please review the code changes for the below issue. >>>>>> >>>>>> Bug : JDK-8016521 : InetAddress should not always re-order >>>>>> addresses returned from name service >>>>>> Webrev : >>>>>> http://cr.openjdk.java.net/~vtewari/8016521/webrev0.0/index.html >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Vyom >>>>>> From michael.x.mcmahon at oracle.com Tue May 17 13:43:09 2016 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 17 May 2016 14:43:09 +0100 Subject: RFR: 8153142: Cannot resolve multiple values from one response header Message-ID: <573B1FED.6000501@oracle.com> Could I get the following change reviewed please? In some circumstances multi-valued response headers were being ignored (except for the first occurrence). The change fixes that problem. It also changes the output of multi-valued request headers to be consistent with that. So instead of sending two headers as: X-Foo: val1, val2 they are sent as X-Foo: val1 X-Foo: val2 It is still possible to do it the other way by constructing the value string as a single header. http://cr.openjdk.java.net/~michaelm/8153142/webrev.1/ Thanks, Michael From chris.hegarty at oracle.com Tue May 17 13:50:44 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 17 May 2016 14:50:44 +0100 Subject: RFR 8016521: InetAddress should not always re-order addresses returned from name service In-Reply-To: <573B1E63.2000008@oracle.com> References: <5731B29F.8010806@oracle.com> <2f153c27-44b3-49fd-9378-0aceedcd8249.maildroid@localhost> <57358100.2020906@oracle.com> <5735D091.6080903@oracle.com> <573AE902.400@oracle.com> <700EF449-4840-416D-8390-5B44B41C8A1F@oracle.com> <573B1E63.2000008@oracle.com> Message-ID: <0E755C33-D45C-424B-978B-BB690B940927@oracle.com> On 17 May 2016, at 14:36, vyom wrote: > Hi Chris, > > Please find the updated webrev(http://cr.openjdk.java.net/~vtewari/8016521/webrev0.3/index.html ). i have did the changes as you suggested. Thanks. The updated webrev look good. -Chris. > Thanks, > Vyom > > > On Tuesday 17 May 2016 05:04 PM, Chris Hegarty wrote: >> On 17 May 2016, at 10:48, vyom wrote: >> >>> Hi Chris, >>> >>> Please find the updated webrev(http://cr.openjdk.java.net/~vtewari/8016521/webrev0.2/index.html ). >> This looks good Vyom. Thanks. >> >> One additional change is needed. Apologies, I forgot that the specification >> of java.net.preferIPv6Addresses was in the source tree and not in the >> guides. We will need to update this, something similar to... >> >> diff --git a/src/java.base/share/classes/java/net/doc-files/net-properties.html b/src/java.base/share/classes/java/net/doc-files/net-properties.html >> --- a/src/java.base/share/classes/java/net/doc-files/net-properties.html >> +++ b/src/java.base/share/classes/java/net/doc-files/net-properties.html >> @@ -58,7 +58,8 @@ >> applications that depend on the representation of an IPv4 address >> (e.g. 192.168.1.1). This property can be set to true to >> change that preference and use IPv6 addresses over IPv4 ones where >> - possible.

>> + possible, or system to preserve the order of the addresses as >> + returned by the operating system.

>> >>

Both of these properties are checked only once, at startup.

>> >> >> If you agree, can you fold it into your patch, and generate a changeset. >> >> -Chris. >> >>> Thanks, >>> Vyom >>> >>> >>> On Friday 13 May 2016 06:33 PM, Chris Hegarty wrote: >>>> Vyom, >>>> >>>> On 13/05/16 08:23, vyom wrote: >>>>> Hi, >>>>> >>>>> Please find the updated >>>>> webrev(http://cr.openjdk.java.net/~vtewari/8016521/webrev0.1/index.html >>>>> ), i >>>>> incorporated the review comments. >>>> This addresses my comments regarding the code. I'm still not >>>> sure what, if anything, we can do in the area of testing, but >>>> maybe that could be done as a follow up. >>>> >>>> One final comment, that I missed earlier. I think >>>> preferIPv6Address can be made final, if you remove the '-1' >>>> initializer. >>>> >>>> -Chris. >>>> >>>>> Thanks, >>>>> Vyom >>>>> >>>>> >>>>> On Thursday 12 May 2016 09:57 PM, Chris Hegarty wrote: >>>>>> On 10 May 2016, at 20:52, ecki at zusammenkunft.net wrote: >>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> Love it. >>>>>> Yes, this is along the same lines as I was thinking. >>>>>> >>>>>>> Not sure about two things, first of all if there are more test cases >>>>>>> (especially assertions) needed and >>>>>> Right. Maybe a new test that, 1) runs in all three modes, and 2) asserts >>>>>> that the order of addressed returned from several different InetAddress >>>>>> getXXX calls, is consistent with what we expect. Though, I?m not sure how >>>>>> to check ?system? other than it must contain the same set of addresses >>>>>> as 'false' or ?true?. >>>>>> >>>>>> I wonder if being able to successfully create a >>>>>> java.io.channels.DatagramChannel.open(StandardProtocolFamily.INET6) >>>>>> is a reliable way to tell if IPv6 is supported. >>>>>> >>>>>>> secondly how to handle the prefer=System case for anyAddr and local. >>>>>>> Currently it seems to prefer v4 (since this is the current default) >>>>>>> howver i would expect in the system case to either detect the >>>>>>> prefered AF or use ipv6 (as of rfc). Returning 127.0.1/0.0.0.0 might >>>>>>> actually make the system based address detection unuseable in v6 >>>>>>> scenarios. >>>>>> I agree. Specifically you talking about Inet6AddressImpl >>>>>> anyLocalAddress() and loopbackAddress(), right? >>>>>> I think the changes in Inet6AddressImpl need to check: >>>>>> >>>>>> if (InetAddress.preferIPv6Address == PREFER_IPV6_VALUE || >>>>>> InetAddress.preferIPv6Address == PREFER_SYSTEM_VALUE) >>>>>> >>>>>> InetAddressImplFactory already checks for ?isIPv6Supported? when >>>>>> determining which impl to create. If an Inet6AddressImpl is created, >>>>>> then IPv6 is supported on the system, therefore either >>>>>> PREFER_SYSTEM_VALUE or PREFER_IPV6_VALUE should >>>>>> cause anyLocalAddress() and loopbackAddress() to return an >>>>>> Inet6Address. >>>>>> >>>>>> >>>>>> Other minor comments: >>>>>> Inet6AddressImpl.java: can you statically import the int values >>>>>> unix Inet6AddressImpl.c. missing space, ?if(?)? L 445 >>>>>> >>>>>> -Chris. >>>>>> >>>>>>> Gruss >>>>>>> Bernd >>>>>>> -- >>>>>>> http://bernd.eckenfels.net >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: vyom >>>>>>> To: net-dev >>>>>>> Sent: Di., 10 Mai 2016 12:36 >>>>>>> Subject: RFR 8016521: InetAddress should not always re-order >>>>>>> addresses returned from name service >>>>>>> >>>>>>> Hi All, >>>>>>> >>>>>>> Please review the code changes for the below issue. >>>>>>> >>>>>>> Bug : JDK-8016521 : InetAddress should not always re-order >>>>>>> addresses returned from name service >>>>>>> Webrev : >>>>>>> http://cr.openjdk.java.net/~vtewari/8016521/webrev0.0/index.html >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Vyom >>>>>>> > From chris.hegarty at oracle.com Tue May 17 13:53:24 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 17 May 2016 14:53:24 +0100 Subject: [OFFLIST] Re: RFR 8016521: InetAddress should not always re-order addresses returned from name service In-Reply-To: <573B1E63.2000008@oracle.com> References: <5731B29F.8010806@oracle.com> <2f153c27-44b3-49fd-9378-0aceedcd8249.maildroid@localhost> <57358100.2020906@oracle.com> <5735D091.6080903@oracle.com> <573AE902.400@oracle.com> <700EF449-4840-416D-8390-5B44B41C8A1F@oracle.com> <573B1E63.2000008@oracle.com> Message-ID: [OFFLIST] The code changes, test updates, etc are done. But we need a CCC request, because you are effectively changing a "public interface?, i.e. the set of allowable values for the documented system property. Are you familiar with CCC? http://ccc.us.oracle.com -Chris. On 17 May 2016, at 14:36, vyom wrote: > Hi Chris, > > Please find the updated webrev(http://cr.openjdk.java.net/~vtewari/8016521/webrev0.3/index.html ). i have did the changes as you suggested. > > Thanks, > Vyom > > > On Tuesday 17 May 2016 05:04 PM, Chris Hegarty wrote: >> On 17 May 2016, at 10:48, vyom wrote: >> >>> Hi Chris, >>> >>> Please find the updated webrev(http://cr.openjdk.java.net/~vtewari/8016521/webrev0.2/index.html ). >> This looks good Vyom. Thanks. >> >> One additional change is needed. Apologies, I forgot that the specification >> of java.net.preferIPv6Addresses was in the source tree and not in the >> guides. We will need to update this, something similar to... >> >> diff --git a/src/java.base/share/classes/java/net/doc-files/net-properties.html b/src/java.base/share/classes/java/net/doc-files/net-properties.html >> --- a/src/java.base/share/classes/java/net/doc-files/net-properties.html >> +++ b/src/java.base/share/classes/java/net/doc-files/net-properties.html >> @@ -58,7 +58,8 @@ >> applications that depend on the representation of an IPv4 address >> (e.g. 192.168.1.1). This property can be set to true to >> change that preference and use IPv6 addresses over IPv4 ones where >> - possible.

>> + possible, or system to preserve the order of the addresses as >> + returned by the operating system.

>> >>

Both of these properties are checked only once, at startup.

>> >> >> If you agree, can you fold it into your patch, and generate a changeset. >> >> -Chris. >> >>> Thanks, >>> Vyom >>> >>> >>> On Friday 13 May 2016 06:33 PM, Chris Hegarty wrote: >>>> Vyom, >>>> >>>> On 13/05/16 08:23, vyom wrote: >>>>> Hi, >>>>> >>>>> Please find the updated >>>>> webrev(http://cr.openjdk.java.net/~vtewari/8016521/webrev0.1/index.html >>>>> ), i >>>>> incorporated the review comments. >>>> This addresses my comments regarding the code. I'm still not >>>> sure what, if anything, we can do in the area of testing, but >>>> maybe that could be done as a follow up. >>>> >>>> One final comment, that I missed earlier. I think >>>> preferIPv6Address can be made final, if you remove the '-1' >>>> initializer. >>>> >>>> -Chris. >>>> >>>>> Thanks, >>>>> Vyom >>>>> >>>>> >>>>> On Thursday 12 May 2016 09:57 PM, Chris Hegarty wrote: >>>>>> On 10 May 2016, at 20:52, ecki at zusammenkunft.net wrote: >>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> Love it. >>>>>> Yes, this is along the same lines as I was thinking. >>>>>> >>>>>>> Not sure about two things, first of all if there are more test cases >>>>>>> (especially assertions) needed and >>>>>> Right. Maybe a new test that, 1) runs in all three modes, and 2) asserts >>>>>> that the order of addressed returned from several different InetAddress >>>>>> getXXX calls, is consistent with what we expect. Though, I?m not sure how >>>>>> to check ?system? other than it must contain the same set of addresses >>>>>> as 'false' or ?true?. >>>>>> >>>>>> I wonder if being able to successfully create a >>>>>> java.io.channels.DatagramChannel.open(StandardProtocolFamily.INET6) >>>>>> is a reliable way to tell if IPv6 is supported. >>>>>> >>>>>>> secondly how to handle the prefer=System case for anyAddr and local. >>>>>>> Currently it seems to prefer v4 (since this is the current default) >>>>>>> howver i would expect in the system case to either detect the >>>>>>> prefered AF or use ipv6 (as of rfc). Returning 127.0.1/0.0.0.0 might >>>>>>> actually make the system based address detection unuseable in v6 >>>>>>> scenarios. >>>>>> I agree. Specifically you talking about Inet6AddressImpl >>>>>> anyLocalAddress() and loopbackAddress(), right? >>>>>> I think the changes in Inet6AddressImpl need to check: >>>>>> >>>>>> if (InetAddress.preferIPv6Address == PREFER_IPV6_VALUE || >>>>>> InetAddress.preferIPv6Address == PREFER_SYSTEM_VALUE) >>>>>> >>>>>> InetAddressImplFactory already checks for ?isIPv6Supported? when >>>>>> determining which impl to create. If an Inet6AddressImpl is created, >>>>>> then IPv6 is supported on the system, therefore either >>>>>> PREFER_SYSTEM_VALUE or PREFER_IPV6_VALUE should >>>>>> cause anyLocalAddress() and loopbackAddress() to return an >>>>>> Inet6Address. >>>>>> >>>>>> >>>>>> Other minor comments: >>>>>> Inet6AddressImpl.java: can you statically import the int values >>>>>> unix Inet6AddressImpl.c. missing space, ?if(?)? L 445 >>>>>> >>>>>> -Chris. >>>>>> >>>>>>> Gruss >>>>>>> Bernd >>>>>>> -- >>>>>>> http://bernd.eckenfels.net >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: vyom >>>>>>> To: net-dev >>>>>>> Sent: Di., 10 Mai 2016 12:36 >>>>>>> Subject: RFR 8016521: InetAddress should not always re-order >>>>>>> addresses returned from name service >>>>>>> >>>>>>> Hi All, >>>>>>> >>>>>>> Please review the code changes for the below issue. >>>>>>> >>>>>>> Bug : JDK-8016521 : InetAddress should not always re-order >>>>>>> addresses returned from name service >>>>>>> Webrev : >>>>>>> http://cr.openjdk.java.net/~vtewari/8016521/webrev0.0/index.html >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Vyom >>>>>>> > From artem.smotrakov at oracle.com Tue May 17 21:27:42 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Tue, 17 May 2016 14:27:42 -0700 Subject: [9] RFR: 8157107: HTTP/2 client may fail with NPE if additional logging enabled Message-ID: <573B8CCE.8000308@oracle.com> Hello, Please review this patch for 9. NPE may occur if additional logging is enabled with "java.net.http.HttpClient.log" system property because AsyncSSLDelegate.logParams(SSLParameters) doesn't check for null values which were returned by SSLParameters instance. I also noticed that setting "java.net.http.HttpClient.log" system property to "all" doesn't enable additional logging for "ssl". Not sure if that was done for some purpose. Changes: - added a couple of checks to AsyncSSLDelegate.logParams(SSLParameters) method to prevent NPEs - updated java/net/http/Log.java to enable logging for "ssl" if "java.net.http.HttpClient.log" system property was set to "all" - updated java/net/http/Http2TestServer.java to implement AutoCloseable, so that it's possible to use it in try-with-resource blocks (which simplifies tests a little bit) - added TLSConnection.java test which run HTTP/2 client with different SSL parameters, and checks that they were actually used - a couple of cosmetic changes (unused imports, etc) TLSConnection.java test also checks that https://bugs.openjdk.java.net/browse/JDK-8150769 was fixed (this bug has been fixed while HTTP/2 integration). Bug: https://bugs.openjdk.java.net/browse/JDK-8157107 Webrev: http://cr.openjdk.java.net/~asmotrak/8157107/webrev.01/ Artem -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.x.mcmahon at oracle.com Wed May 18 13:36:14 2016 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 18 May 2016 14:36:14 +0100 Subject: [9] RFR: 8157107: HTTP/2 client may fail with NPE if additional logging enabled In-Reply-To: <573B8CCE.8000308@oracle.com> References: <573B8CCE.8000308@oracle.com> Message-ID: <573C6FCE.1060307@oracle.com> Looks good, Artem. Thanks, Michael On 17/05/16 22:27, Artem Smotrakov wrote: > Hello, > > Please review this patch for 9. > > NPE may occur if additional logging is enabled with > "java.net.http.HttpClient.log" system property because > AsyncSSLDelegate.logParams(SSLParameters) doesn't check for null > values which were returned by SSLParameters instance. > > I also noticed that setting "java.net.http.HttpClient.log" system > property to "all" doesn't enable additional logging for "ssl". Not > sure if that was done for some purpose. > > Changes: > - added a couple of checks to > AsyncSSLDelegate.logParams(SSLParameters) method to prevent NPEs > - updated java/net/http/Log.java to enable logging for "ssl" if > "java.net.http.HttpClient.log" system property was set to "all" > - updated java/net/http/Http2TestServer.java to implement > AutoCloseable, so that it's possible to use it in try-with-resource > blocks (which simplifies tests a little bit) > - added TLSConnection.java test which run HTTP/2 client with different > SSL parameters, and checks that they were actually used > - a couple of cosmetic changes (unused imports, etc) > > TLSConnection.java test also checks that > https://bugs.openjdk.java.net/browse/JDK-8150769 was fixed (this bug > has been fixed while HTTP/2 integration). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8157107 > Webrev: http://cr.openjdk.java.net/~asmotrak/8157107/webrev.01/ > > Artem -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.x.mcmahon at oracle.com Wed May 18 16:55:16 2016 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 18 May 2016 17:55:16 +0100 Subject: RFR 8157105: HTTP/2 client hangs in blocking mode if an invalid frame has been received Message-ID: <573C9E74.1070804@oracle.com> Could I get the following change reviewed please? http://cr.openjdk.java.net/~michaelm/8157105/webrev.1/ Some error conditions not being handled correctly and some logging cleanup. Thanks Michael. From Roger.Riggs at Oracle.com Wed May 18 17:11:02 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 18 May 2016 13:11:02 -0400 Subject: RFR: 8153142: Cannot resolve multiple values from one response header In-Reply-To: <573B1FED.6000501@oracle.com> References: <573B1FED.6000501@oracle.com> Message-ID: Hi Michael, Looks fine. Roger On 5/17/2016 9:43 AM, Michael McMahon wrote: > Could I get the following change reviewed please? > > In some circumstances multi-valued response headers > were being ignored (except for the first occurrence). > The change fixes that problem. It also changes the > output of multi-valued request headers to be consistent with that. > > So instead of sending two headers as: > > X-Foo: val1, val2 > > they are sent as > > X-Foo: val1 > X-Foo: val2 > > It is still possible to do it the other way by constructing the > value string as a single header. > > http://cr.openjdk.java.net/~michaelm/8153142/webrev.1/ > > Thanks, > Michael From anthony.vanelverdinghe at gmail.com Thu May 19 13:54:36 2016 From: anthony.vanelverdinghe at gmail.com (Anthony Vanelverdinghe) Date: Thu, 19 May 2016 15:54:36 +0200 Subject: JEP 110: leeway for API changes? Message-ID: Hi With the JDK's "Feature Complete" milestone coming up next week: how much leeway is there still for API changes? I've made API suggestions (a.o. in [1]), ranging from changing HttpResponse.multiProcessor::onStart's return type (from BiFunction<..., Boolean> to BiPredicate), to building on the j.u.c.Flow API & eliminating HttpResponse.MultiProcessor. So I'm wondering what's still on on the table for JEP 110 w.r.t. API changes? [1] http://mail.openjdk.java.net/pipermail/net-dev/2016-March/009608.html Kind regards, Anthony From simone.bordet at gmail.com Thu May 19 14:02:44 2016 From: simone.bordet at gmail.com (Simone Bordet) Date: Thu, 19 May 2016 16:02:44 +0200 Subject: JEP 110: leeway for API changes? In-Reply-To: References: Message-ID: Hi, On Thu, May 19, 2016 at 3:54 PM, Anthony Vanelverdinghe wrote: > Hi > > With the JDK's "Feature Complete" milestone coming up next week: how much > leeway is there still for API changes? I've made API suggestions (a.o. in > [1]), ranging from changing HttpResponse.multiProcessor::onStart's return > type (from BiFunction<..., Boolean> to BiPredicate), to building on the > j.u.c.Flow API & eliminating HttpResponse.MultiProcessor. So I'm wondering > what's still on on the table for JEP 110 w.r.t. API changes? I second that. I also made API change proposals, but no feedback. -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From svetlana.nikandrova at oracle.com Thu May 19 16:13:32 2016 From: svetlana.nikandrova at oracle.com (Svetlana Nikandrova) Date: Thu, 19 May 2016 19:13:32 +0300 Subject: RFR 8136933: Additional tests for Solaris SO_FLOW_SLA socket option in JDK 9 Message-ID: <573DE62C.7020300@oracle.com> Hello, please review additional test for Solaris SO_FLOW_SLA socket option. Test checks that SO_FLOW_SLA option is supported on Solaris 11.2+ and not supported on other platforms. http://cr.openjdk.java.net/~snikandrova/8136933/webrev.00/ Thank you, Svetlana From artem.smotrakov at oracle.com Thu May 19 16:51:53 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Thu, 19 May 2016 09:51:53 -0700 Subject: RFR 8136933: Additional tests for Solaris SO_FLOW_SLA socket option in JDK 9 In-Reply-To: <573DE62C.7020300@oracle.com> References: <573DE62C.7020300@oracle.com> Message-ID: <573DEF29.7090201@oracle.com> Hi Svetlana, Please see a couple of comments below. I'll leave the final review to official reviewers. 1. You may use test/lib/testlibrary/jdk/testlibrary/OSInfo.java to check OS type. I think it also may be good to add getSolarisVersion() to OSInfo.java (see getWindowsVersion() method) You can also use ProcessTools.java in getSolarisVersion() 2. line 46: Did you mean java.lang.String 3. Should it throw an exception after lines 173 and 181? Or, this may depend on other constraints? I see you added a comment for checkSocketOption() method, but it maybe better to clarify why no exception is also fine. I am also wondering if it should expect no exception in getOption() if setOption() succeeded. Artem On 05/19/2016 09:13 AM, Svetlana Nikandrova wrote: > Hello, > > please review additional test for Solaris SO_FLOW_SLA socket option. > Test checks that SO_FLOW_SLA option is supported on Solaris 11.2+ and > not supported on other platforms. > > http://cr.openjdk.java.net/~snikandrova/8136933/webrev.00/ > > > Thank you, > Svetlana -------------- next part -------------- An HTML attachment was scrubbed... URL: From Roger.Riggs at Oracle.com Thu May 19 17:07:14 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 19 May 2016 13:07:14 -0400 Subject: RFR 8157105: HTTP/2 client hangs in blocking mode if an invalid frame has been received In-Reply-To: <573C9E74.1070804@oracle.com> References: <573C9E74.1070804@oracle.com> Message-ID: <5be6416b-32b4-43af-2a69-ee11c3900522@Oracle.com> Hi Michael, Look ok, A one line description of the error it is trying to produce would be a good addition. Either in comment, javadoc or @summary Roger On 5/18/2016 12:55 PM, Michael McMahon wrote: > Could I get the following change reviewed please? > > http://cr.openjdk.java.net/~michaelm/8157105/webrev.1/ > > Some error conditions not being handled correctly and some > logging cleanup. > > Thanks > Michael. > From vyom.tewari at oracle.com Fri May 20 08:50:57 2016 From: vyom.tewari at oracle.com (vyom) Date: Fri, 20 May 2016 14:20:57 +0530 Subject: RFR 8048520 :File Descriptor Leak in jdk/src/solaris/native/java/net/net_util_md.c Message-ID: <573ECFF1.5040409@oracle.com> Hi, Please review the simple fix for below issue. Bug: JDK-8048520 :File Descriptor Leak in jdk/src/solaris/native/java/net/net_util_md.c Webrev: http://cr.openjdk.java.net/~vtewari/8048520/webrev0.0/index.html Thanks, Vyom From Alan.Bateman at oracle.com Fri May 20 08:53:00 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 20 May 2016 09:53:00 +0100 Subject: RFR 8048520 :File Descriptor Leak in jdk/src/solaris/native/java/net/net_util_md.c In-Reply-To: <573ECFF1.5040409@oracle.com> References: <573ECFF1.5040409@oracle.com> Message-ID: <573ED06C.80506@oracle.com> On 20/05/2016 09:50, vyom wrote: > Hi, > > Please review the simple fix for below issue. > > Bug: JDK-8048520 :File Descriptor Leak in > jdk/src/solaris/native/java/net/net_util_md.c > > Webrev: > http://cr.openjdk.java.net/~vtewari/8048520/webrev0.0/index.html > This looks okay to me. Just to check, have you scanned the other error cases to see that we don't have this issue elsewhere? -Alan From chris.hegarty at oracle.com Fri May 20 09:30:16 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 20 May 2016 10:30:16 +0100 Subject: RFR 8048520 :File Descriptor Leak in jdk/src/solaris/native/java/net/net_util_md.c In-Reply-To: <573ECFF1.5040409@oracle.com> References: <573ECFF1.5040409@oracle.com> Message-ID: <262596AF-2077-40C0-9C15-5DD45CE57A8C@oracle.com> Looks good Vyom. I will sponsor this for you. -Chris > On 20 May 2016, at 09:50, vyom wrote: > > Hi, > > Please review the simple fix for below issue. > > Bug: JDK-8048520 :File Descriptor Leak in jdk/src/solaris/native/java/net/net_util_md.c > > Webrev: http://cr.openjdk.java.net/~vtewari/8048520/webrev0.0/index.html > > Thanks, > Vyom > From svetlana.nikandrova at oracle.com Fri May 20 10:16:17 2016 From: svetlana.nikandrova at oracle.com (Svetlana Nikandrova) Date: Fri, 20 May 2016 13:16:17 +0300 Subject: RFR 8136933: Additional tests for Solaris SO_FLOW_SLA socket option in JDK 9 In-Reply-To: <573DEF29.7090201@oracle.com> References: <573DE62C.7020300@oracle.com> <573DEF29.7090201@oracle.com> Message-ID: <573EE3F1.1000109@oracle.com> Hi Artem, thank you for your comments. Please see updated review: http://cr.openjdk.java.net/~snikandrova/8136933/webrev.01/ I've moved version check to OSInfo.java and used ProcessTools. Also made a little change in ProcessTools (Throwable didn't make sense there). I also updated comment for checkSocketOption() method to indicate that it is fine to not get any exception. Actually as this test is meant to check platform support we are only interested in UnssuportedOperationException. More usage scenarios with SO_FLOW_SLA option are covered by http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/tip/test/jdk/net/Sockets/Test.java Thank you, Svetlana On 19.05.2016 19:51, Artem Smotrakov wrote: > Hi Svetlana, > > Please see a couple of comments below. I'll leave the final review to > official reviewers. > > 1. You may use test/lib/testlibrary/jdk/testlibrary/OSInfo.java to > check OS type. I think it also may be good to add getSolarisVersion() > to OSInfo.java (see getWindowsVersion() method) > > You can also use ProcessTools.java in getSolarisVersion() > > 2. line 46: Did you mean java.lang.String > > 3. Should it throw an exception after lines 173 and 181? Or, this may > depend on other constraints? I see you added a comment for > checkSocketOption() method, but it maybe better to clarify why no > exception is also fine. > > I am also wondering if it should expect no exception in getOption() if > setOption() succeeded. > > Artem > > On 05/19/2016 09:13 AM, Svetlana Nikandrova wrote: >> Hello, >> >> please review additional test for Solaris SO_FLOW_SLA socket option. >> Test checks that SO_FLOW_SLA option is supported on Solaris 11.2+ and >> not supported on other platforms. >> >> http://cr.openjdk.java.net/~snikandrova/8136933/webrev.00/ >> >> >> Thank you, >> Svetlana > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Fri May 20 12:07:49 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 20 May 2016 13:07:49 +0100 Subject: RFR 8136933: Additional tests for Solaris SO_FLOW_SLA socket option in JDK 9 In-Reply-To: <573EE3F1.1000109@oracle.com> References: <573DE62C.7020300@oracle.com> <573DEF29.7090201@oracle.com> <573EE3F1.1000109@oracle.com> Message-ID: <573EFE15.2080102@oracle.com> On 20/05/2016 11:16, Svetlana Nikandrova wrote: > Hi Artem, > > thank you for your comments. Please see updated review: > http://cr.openjdk.java.net/~snikandrova/8136933/webrev.01/ > > > I've moved version check to OSInfo.java and used ProcessTools. Also > made a little change in ProcessTools (Throwable didn't make sense > there). I also updated comment for checkSocketOption() method to > indicate that it is fine to not get any exception. Actually as this > test is meant to check platform support we are only interested in > UnssuportedOperationException. More usage scenarios with SO_FLOW_SLA > option are covered by > http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/tip/test/jdk/net/Sockets/Test.java Yes, there is an existing test in test/jdk/net/Sockets/Test.java and seems strange to have the tests in different locations (maybe some overlapping coverage too). -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From svetlana.nikandrova at oracle.com Fri May 20 13:05:24 2016 From: svetlana.nikandrova at oracle.com (Svetlana Nikandrova) Date: Fri, 20 May 2016 16:05:24 +0300 Subject: RFR 8136933: Additional tests for Solaris SO_FLOW_SLA socket option in JDK 9 In-Reply-To: <573EFE15.2080102@oracle.com> References: <573DE62C.7020300@oracle.com> <573DEF29.7090201@oracle.com> <573EE3F1.1000109@oracle.com> <573EFE15.2080102@oracle.com> Message-ID: <573F0B94.4020803@oracle.com> Alan, another test related to this option is on the same level (test/jdk/net/SocketFlow) so I thought it's ok to maintain the same hierarchy. I can move test to test/jdk/net/Sockets/ExtendedSocketOptions/SO_FLOW_SLA or to test/jdk/net/Sockets, but in that case won't it be a little bit confusing? As for overlapping coverage: existing test silently exits if option is not in supported list while this one is focused on platform support check. Thank you, Svetlana On 20.05.2016 15:07, Alan Bateman wrote: > On 20/05/2016 11:16, Svetlana Nikandrova wrote: >> Hi Artem, >> >> thank you for your comments. Please see updated review: >> http://cr.openjdk.java.net/~snikandrova/8136933/webrev.01/ >> >> >> I've moved version check to OSInfo.java and used ProcessTools. Also >> made a little change in ProcessTools (Throwable didn't make sense >> there). I also updated comment for checkSocketOption() method to >> indicate that it is fine to not get any exception. Actually as this >> test is meant to check platform support we are only interested in >> UnssuportedOperationException. More usage scenarios with SO_FLOW_SLA >> option are covered by >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/tip/test/jdk/net/Sockets/Test.java > Yes, there is an existing test in test/jdk/net/Sockets/Test.java and > seems strange to have the tests in different locations (maybe some > overlapping coverage too). > > -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Fri May 20 13:10:19 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 20 May 2016 14:10:19 +0100 Subject: RFR 8136933: Additional tests for Solaris SO_FLOW_SLA socket option in JDK 9 In-Reply-To: <573F0B94.4020803@oracle.com> References: <573DE62C.7020300@oracle.com> <573DEF29.7090201@oracle.com> <573EE3F1.1000109@oracle.com> <573EFE15.2080102@oracle.com> <573F0B94.4020803@oracle.com> Message-ID: <573F0CBB.2060600@oracle.com> On 20/05/2016 14:05, Svetlana Nikandrova wrote: > Alan, > > another test related to this option is on the same level > (test/jdk/net/SocketFlow) so I thought it's ok to maintain the same > hierarchy. I can move test to > test/jdk/net/Sockets/ExtendedSocketOptions/SO_FLOW_SLA or to > test/jdk/net/Sockets, but in that case won't it be a little bit confusing? > > As for overlapping coverage: existing test silently exits if option is > not in supported list while this one is focused on platform support > check. I think it would be good to put all the tests in the same place, will make it easier for further maintenance in this area. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Fri May 20 15:19:19 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 20 May 2016 16:19:19 +0100 Subject: RFR 8136933: Additional tests for Solaris SO_FLOW_SLA socket option in JDK 9 In-Reply-To: <573F0CBB.2060600@oracle.com> References: <573DE62C.7020300@oracle.com> <573DEF29.7090201@oracle.com> <573EE3F1.1000109@oracle.com> <573EFE15.2080102@oracle.com> <573F0B94.4020803@oracle.com> <573F0CBB.2060600@oracle.com> Message-ID: <3BF32E17-9F82-423C-8351-EF27CCF0393B@oracle.com> > On 20 May 2016, at 14:10, Alan Bateman wrote: > > On 20/05/2016 14:05, Svetlana Nikandrova wrote: >> Alan, >> >> another test related to this option is on the same level (test/jdk/net/SocketFlow) I added this recently, when working on a different issue, when I noticed that there were no tests for the SocketFllow API, regardless of the underlying system support. The test directory structure matches the class package/name hierarchy. >> so I thought it's ok to maintain the same hierarchy. I can move test to test/jdk/net/Sockets/ExtendedSocketOptions/SO_FLOW_SLA or to test/jdk/net/Sockets, but in that case won't it be a little bit confusing? >> >> As for overlapping coverage: existing test silently exits if option is not in supported list while this one is focused on platform support check. > I think it would be good to put all the tests in the same place, will make it easier for further maintenance in this area. The proposed new test seems, somewhat, to be a replacement for test/jdk/net/Sockets/Test.java, but it does not assert that if set succeeds that get should return something useful? Also set typically cannot succeed unless run with privileges. The test also seems to focus on setting the option through the idk.net.Sockets API rather than through the setOption of the socket types, any reason for this? The jdk.net.Sockets API should be deprecated in 9, as we have a standard replacement. When working in the area previously, I ran test/jdk/net/Sockets/Test.java manually and examined the output to determine that the option was being set correctly. It this test is merely to check that the option is supported on S 11.2 +, then maybe that could be added to the existing test/jdk/net/Sockets/Test.java ? -Chris. From vyom.tewari at oracle.com Mon May 23 04:04:55 2016 From: vyom.tewari at oracle.com (vyom) Date: Mon, 23 May 2016 09:34:55 +0530 Subject: RFR 8143923 :DatagramSocket and MulticastSocket supportedOptions set depends on call order Message-ID: <57428167.20004@oracle.com> Hi All, Please review the below code change. Bug : JDK-8143923 DatagramSocket and MulticastSocket supportedOptions set depends on call order Webrev : http://cr.openjdk.java.net/~vtewari/8143923/webrev0.0/index.html I found the same problem in java.net.Socket/ServerSocket, i did the code changes for them as well. Thanks, Vyom From amy.lu at oracle.com Mon May 23 06:39:12 2016 From: amy.lu at oracle.com (Amy Lu) Date: Mon, 23 May 2016 14:39:12 +0800 Subject: JDK 9 RFR of JDK-8157499: Mark several tests from jdk_net as intermittently failing Message-ID: <5742A590.2010604@oracle.com> Below tests are known to fail intermittently. This patch is to mark the test accordingly with keyword 'intermittent? until issue resolved. java/net/MulticastSocket/TestInterfaces.java (JDK-8134989) java/net/DatagramSocket/PortUnreachable.java (JDK-8085875) java/net/InetAddress/IsReachableViaLoopbackTest.java (JDK-8139929) sun/net/www/http/ChunkedOutputStream/checkError.java (JDK-8041924) bug: https://bugs.openjdk.java.net/browse/JDK-8157499 webrev: http://cr.openjdk.java.net/~amlu/8157499/webrev.00/ Thanks, Amy --- old/test/java/net/DatagramSocket/PortUnreachable.java 2016-05-23 14:31:49.000000000 +0800 +++ new/test/java/net/DatagramSocket/PortUnreachable.java 2016-05-23 14:31:49.000000000 +0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2000, 2013 Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2000, 2016, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -24,6 +24,7 @@ /** * @test * @bug 4361783 + * @key intermittent * @summary Test to see if ICMP Port Unreachable on non-connected * DatagramSocket causes a SocketException "socket closed" * exception on Windows 2000. --- old/test/java/net/InetAddress/IsReachableViaLoopbackTest.java 2016-05-23 14:31:50.000000000 +0800 +++ new/test/java/net/InetAddress/IsReachableViaLoopbackTest.java 2016-05-23 14:31:50.000000000 +0800 @@ -5,6 +5,7 @@ /** * @test * @bug 8135305 + * @key intermittent * @summary ensure we can't ping external hosts via loopback if */ --- old/test/java/net/MulticastSocket/TestInterfaces.java 2016-05-23 14:31:50.000000000 +0800 +++ new/test/java/net/MulticastSocket/TestInterfaces.java 2016-05-23 14:31:50.000000000 +0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2001, 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2001, 2016, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -24,6 +24,7 @@ /* * @test * @bug 4422122 + * @key intermittent * @summary Test that MulticastSocket.getInterface returns the * same InetAddress set by MulticastSocket.setInterface */ --- old/test/sun/net/www/http/ChunkedOutputStream/checkError.java 2016-05-23 14:31:51.000000000 +0800 +++ new/test/sun/net/www/http/ChunkedOutputStream/checkError.java 2016-05-23 14:31:51.000000000 +0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2004, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2004, 2016, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -24,6 +24,7 @@ /** * @test * @bug 5054016 + * @key intermittent * @run main/othervm/timeout=300 checkError * @summary get the failure immediately when writing individual chunks over socket fail */ -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.x.mcmahon at oracle.com Mon May 23 11:51:23 2016 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 23 May 2016 12:51:23 +0100 Subject: JEP 110: leeway for API changes? In-Reply-To: References: Message-ID: <5742EEBB.3090006@oracle.com> Hi, API changes are still possible. Sorry, I haven't gotten around to replying to all feedback, but I will do this week. Thanks Michael On 19/05/16 15:02, Simone Bordet wrote: > Hi, > > On Thu, May 19, 2016 at 3:54 PM, Anthony Vanelverdinghe > wrote: >> Hi >> >> With the JDK's "Feature Complete" milestone coming up next week: how much >> leeway is there still for API changes? I've made API suggestions (a.o. in >> [1]), ranging from changing HttpResponse.multiProcessor::onStart's return >> type (from BiFunction<..., Boolean> to BiPredicate), to building on the >> j.u.c.Flow API & eliminating HttpResponse.MultiProcessor. So I'm wondering >> what's still on on the table for JEP 110 w.r.t. API changes? > I second that. I also made API change proposals, but no feedback. > From chris.hegarty at oracle.com Mon May 23 12:45:41 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 23 May 2016 13:45:41 +0100 Subject: JDK 9 RFR of JDK-8157499: Mark several tests from jdk_net as intermittently failing In-Reply-To: <5742A590.2010604@oracle.com> References: <5742A590.2010604@oracle.com> Message-ID: <5742FB75.3010502@oracle.com> On 23/05/16 07:39, Amy Lu wrote: > Below tests are known to fail intermittently. This patch is to mark the > test accordingly with keyword 'intermittent? until issue resolved. > > java/net/MulticastSocket/TestInterfaces.java (JDK-8134989) > java/net/DatagramSocket/PortUnreachable.java (JDK-8085875) > java/net/InetAddress/IsReachableViaLoopbackTest.java (JDK-8139929) > sun/net/www/http/ChunkedOutputStream/checkError.java (JDK-8041924) > > bug: https://bugs.openjdk.java.net/browse/JDK-8157499 > webrev: http://cr.openjdk.java.net/~amlu/8157499/webrev.00/ Looks ok to me Amy. Thanks. -Chris. > Thanks, > Amy > > > --- old/test/java/net/DatagramSocket/PortUnreachable.java 2016-05-23 14:31:49.000000000 +0800 > +++ new/test/java/net/DatagramSocket/PortUnreachable.java 2016-05-23 14:31:49.000000000 +0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2000, 2013 Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2000, 2016, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -24,6 +24,7 @@ > /** > * @test > * @bug 4361783 > + * @key intermittent > * @summary Test to see if ICMP Port Unreachable on non-connected > * DatagramSocket causes a SocketException "socket closed" > * exception on Windows 2000. > --- old/test/java/net/InetAddress/IsReachableViaLoopbackTest.java 2016-05-23 14:31:50.000000000 +0800 > +++ new/test/java/net/InetAddress/IsReachableViaLoopbackTest.java 2016-05-23 14:31:50.000000000 +0800 > @@ -5,6 +5,7 @@ > /** > * @test > * @bug 8135305 > + * @key intermittent > * @summary ensure we can't ping external hosts via loopback if > */ > > --- old/test/java/net/MulticastSocket/TestInterfaces.java 2016-05-23 14:31:50.000000000 +0800 > +++ new/test/java/net/MulticastSocket/TestInterfaces.java 2016-05-23 14:31:50.000000000 +0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2001, 2013, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2001, 2016, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -24,6 +24,7 @@ > /* > * @test > * @bug 4422122 > + * @key intermittent > * @summary Test that MulticastSocket.getInterface returns the > * same InetAddress set by MulticastSocket.setInterface > */ > --- old/test/sun/net/www/http/ChunkedOutputStream/checkError.java 2016-05-23 14:31:51.000000000 +0800 > +++ new/test/sun/net/www/http/ChunkedOutputStream/checkError.java 2016-05-23 14:31:51.000000000 +0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2004, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2004, 2016, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -24,6 +24,7 @@ > /** > * @test > * @bug 5054016 > + * @key intermittent > * @run main/othervm/timeout=300 checkError > * @summary get the failure immediately when writing individual chunks over socket fail > */ > > From chris.hegarty at oracle.com Mon May 23 13:34:52 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 23 May 2016 14:34:52 +0100 Subject: RFR 8143923 :DatagramSocket and MulticastSocket supportedOptions set depends on call order In-Reply-To: <57428167.20004@oracle.com> References: <57428167.20004@oracle.com> Message-ID: <574306FC.6060008@oracle.com> On 23/05/16 05:04, vyom wrote: > Hi All, > > Please review the below code change. > > Bug : JDK-8143923 DatagramSocket and MulticastSocket > supportedOptions set depends on call order > > Webrev : > http://cr.openjdk.java.net/~vtewari/8143923/webrev0.0/index.html > This looks ok to me Vyom. -Chris. From svetlana.nikandrova at oracle.com Mon May 23 16:36:18 2016 From: svetlana.nikandrova at oracle.com (Svetlana Nikandrova) Date: Mon, 23 May 2016 19:36:18 +0300 Subject: RFR 8136933: Additional tests for Solaris SO_FLOW_SLA socket option in JDK 9 In-Reply-To: <3BF32E17-9F82-423C-8351-EF27CCF0393B@oracle.com> References: <573DE62C.7020300@oracle.com> <573DEF29.7090201@oracle.com> <573EE3F1.1000109@oracle.com> <573EFE15.2080102@oracle.com> <573F0B94.4020803@oracle.com> <573F0CBB.2060600@oracle.com> <3BF32E17-9F82-423C-8351-EF27CCF0393B@oracle.com> Message-ID: <57433182.2080902@oracle.com> Alan, Chris, thank you for your comments. I've decided to do as Chris suggested and updated existing test test/jdk/net/Sockets/Test.java instead of creating a new one. Please see updated review: http://cr.openjdk.java.net/~snikandrova/8136933/webrev.03/ Thank you, Svetlana On 20.05.2016 18:19, Chris Hegarty wrote: >> On 20 May 2016, at 14:10, Alan Bateman wrote: >> >> On 20/05/2016 14:05, Svetlana Nikandrova wrote: >>> Alan, >>> >>> another test related to this option is on the same level (test/jdk/net/SocketFlow) > I added this recently, when working on a different issue, when I > noticed that there were no tests for the SocketFllow API, regardless > of the underlying system support. The test directory structure > matches the class package/name hierarchy. > >>> so I thought it's ok to maintain the same hierarchy. I can move test to test/jdk/net/Sockets/ExtendedSocketOptions/SO_FLOW_SLA or to test/jdk/net/Sockets, but in that case won't it be a little bit confusing? >>> >>> As for overlapping coverage: existing test silently exits if option is not in supported list while this one is focused on platform support check. >> I think it would be good to put all the tests in the same place, will make it easier for further maintenance in this area. > The proposed new test seems, somewhat, to be a replacement for > test/jdk/net/Sockets/Test.java, but it does not assert that if set > succeeds that get should return something useful? Also set > typically cannot succeed unless run with privileges. The test also > seems to focus on setting the option through the idk.net.Sockets API > rather than through the setOption of the socket types, any reason > for this? The jdk.net.Sockets API should be deprecated in 9, as > we have a standard replacement. > > When working in the area previously, I ran > test/jdk/net/Sockets/Test.java manually and examined the output > to determine that the option was being set correctly. > > It this test is merely to check that the option is supported on > S 11.2 +, then maybe that could be added to the existing > test/jdk/net/Sockets/Test.java ? > > -Chris. From chris.hegarty at oracle.com Mon May 23 22:05:25 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 23 May 2016 23:05:25 +0100 Subject: RFR [9] 8155086: Replace usage of -Djdk.launcher.limitmods in tests with -limitmods Message-ID: Replace usage of -Djdk.launcher.limitmods, in several networking and NIO tests, with -limitmods now that jtreg with support for -limitmods is available. -Chris. diff --git a/test/java/net/SocketOption/OptionsTest.java b/test/java/net/SocketOption/OptionsTest.java --- a/test/java/net/SocketOption/OptionsTest.java +++ b/test/java/net/SocketOption/OptionsTest.java @@ -26,7 +26,7 @@ * @bug 8036979 8072384 8044773 * @run main/othervm -Xcheck:jni OptionsTest * @run main/othervm -Xcheck:jni -Djava.net.preferIPv4Stack=true OptionsTest - * @run main/othervm -Djdk.launcher.limitmods=java.base OptionsTest + * @run main/othervm -limitmods java.base OptionsTest */ import java.lang.reflect.Method; diff --git a/test/java/net/SocketOption/UnsupportedOptionsTest.java b/test/java/net/SocketOption/UnsupportedOptionsTest.java --- a/test/java/net/SocketOption/UnsupportedOptionsTest.java +++ b/test/java/net/SocketOption/UnsupportedOptionsTest.java @@ -33,7 +33,7 @@ * @summary Test checks that UnsupportedOperationException for unsupported * SOCKET_OPTIONS is thrown by both getOption() and setOption() methods. * @run main UnsupportedOptionsTest - * @run main/othervm -Djdk.launcher.limitmods=java.base UnsupportedOptionsTest + * @run main/othervm -limitmods java.base UnsupportedOptionsTest */ public class UnsupportedOptionsTest { diff --git a/test/java/nio/channels/DatagramChannel/SocketOptionTests.java b/test/java/nio/channels/DatagramChannel/SocketOptionTests.java --- a/test/java/nio/channels/DatagramChannel/SocketOptionTests.java +++ b/test/java/nio/channels/DatagramChannel/SocketOptionTests.java @@ -25,7 +25,7 @@ * @bug 4640544 8044773 * @summary Unit test for setOption/getOption/options methods * @run main SocketOptionTests - * @run main/othervm -Djdk.launcher.limitmods=java.base SocketOptionTests + * @run main/othervm -limitmods java.base SocketOptionTests */ import java.nio.*; diff --git a/test/java/nio/channels/ServerSocketChannel/SocketOptionTests.java b/test/java/nio/channels/ServerSocketChannel/SocketOptionTests.java --- a/test/java/nio/channels/ServerSocketChannel/SocketOptionTests.java +++ b/test/java/nio/channels/ServerSocketChannel/SocketOptionTests.java @@ -26,7 +26,7 @@ * @summary Unit test for ServerSocketChannel setOption/getOption/options * methods. * @run main SocketOptionTests - * @run main/othervm -Djdk.launcher.limitmods=java.base SocketOptionTests + * @run main/othervm -limitmods java.base SocketOptionTests */ import java.nio.*; diff --git a/test/java/nio/channels/SocketChannel/SocketOptionTests.java b/test/java/nio/channels/SocketChannel/SocketOptionTests.java --- a/test/java/nio/channels/SocketChannel/SocketOptionTests.java +++ b/test/java/nio/channels/SocketChannel/SocketOptionTests.java @@ -26,7 +26,7 @@ * @summary Unit test to check SocketChannel setOption/getOption/options * methods. * @run main SocketOptionTests - * @run main/othervm -Djdk.launcher.limitmods=java.base SocketOptionTests + * @run main/othervm -limitmods java.base SocketOptionTests */ import java.nio.*; -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue May 24 06:42:52 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 24 May 2016 07:42:52 +0100 Subject: RFR [9] 8155086: Replace usage of -Djdk.launcher.limitmods in tests with -limitmods In-Reply-To: References: Message-ID: <5743F7EC.9060404@oracle.com> On 23/05/2016 23:05, Chris Hegarty wrote: > Replace usage of -Djdk.launcher.limitmods, in several networking and > NIO tests, with -limitmods now that jtreg with support for -limitmods is > available. > Looks fine. I think Mandy has switched this for an upcoming patch too. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From svetlana.nikandrova at oracle.com Tue May 24 16:21:35 2016 From: svetlana.nikandrova at oracle.com (Svetlana Nikandrova) Date: Tue, 24 May 2016 19:21:35 +0300 Subject: RFR 8136933: Additional tests for Solaris SO_FLOW_SLA socket option in JDK 9 In-Reply-To: <57433182.2080902@oracle.com> References: <573DE62C.7020300@oracle.com> <573DEF29.7090201@oracle.com> <573EE3F1.1000109@oracle.com> <573EFE15.2080102@oracle.com> <573F0B94.4020803@oracle.com> <573F0CBB.2060600@oracle.com> <3BF32E17-9F82-423C-8351-EF27CCF0393B@oracle.com> <57433182.2080902@oracle.com> Message-ID: <57447F8F.4000709@oracle.com> I hate being annoying, but may be you can find another minute to review updated diff? Thank you, Svetlana On 23.05.2016 19:36, Svetlana Nikandrova wrote: > Alan, Chris, > > thank you for your comments. I've decided to do as Chris suggested and > updated existing test test/jdk/net/Sockets/Test.java instead of > creating a new one. > Please see updated review: > > http://cr.openjdk.java.net/~snikandrova/8136933/webrev.03/ > > > Thank you, > Svetlana > > On 20.05.2016 18:19, Chris Hegarty wrote: >>> On 20 May 2016, at 14:10, Alan Bateman wrote: >>> >>> On 20/05/2016 14:05, Svetlana Nikandrova wrote: >>>> Alan, >>>> >>>> another test related to this option is on the same level >>>> (test/jdk/net/SocketFlow) >> I added this recently, when working on a different issue, when I >> noticed that there were no tests for the SocketFllow API, regardless >> of the underlying system support. The test directory structure >> matches the class package/name hierarchy. >> >>>> so I thought it's ok to maintain the same hierarchy. I can move >>>> test to test/jdk/net/Sockets/ExtendedSocketOptions/SO_FLOW_SLA or >>>> to test/jdk/net/Sockets, but in that case won't it be a little bit >>>> confusing? >>>> >>>> As for overlapping coverage: existing test silently exits if option >>>> is not in supported list while this one is focused on platform >>>> support check. >>> I think it would be good to put all the tests in the same place, >>> will make it easier for further maintenance in this area. >> The proposed new test seems, somewhat, to be a replacement for >> test/jdk/net/Sockets/Test.java, but it does not assert that if set >> succeeds that get should return something useful? Also set >> typically cannot succeed unless run with privileges. The test also >> seems to focus on setting the option through the idk.net.Sockets API >> rather than through the setOption of the socket types, any reason >> for this? The jdk.net.Sockets API should be deprecated in 9, as >> we have a standard replacement. >> >> When working in the area previously, I ran >> test/jdk/net/Sockets/Test.java manually and examined the output >> to determine that the option was being set correctly. >> >> It this test is merely to check that the option is supported on >> S 11.2 +, then maybe that could be added to the existing >> test/jdk/net/Sockets/Test.java ? >> >> -Chris. > From martinrb at google.com Tue May 24 17:49:09 2016 From: martinrb at google.com (Martin Buchholz) Date: Tue, 24 May 2016 10:49:09 -0700 Subject: JDK-8148424 Support IPv6-only Unix environments In-Reply-To: <02A5EAA0-C1AB-47C3-8D06-7DA16EC5458E@oracle.com> References: <02A5EAA0-C1AB-47C3-8D06-7DA16EC5458E@oracle.com> Message-ID: I'm (slowly) working on getting you more ipv6 stuff... On Thu, May 12, 2016 at 8:32 AM, Chris Hegarty wrote: > Martin, > > Promoted by some other changes that are going on, I stumbled > across your proposal for 8148424: "Support IPv6-only Unix > environments? [1][2][3]. > > I think the changes are good. I rebased them against the latest > source in jdk9/dev. > > http://cr.openjdk.java.net/~chegar/8148424/ > > I put the changes through our build and test system, and there > are no surprising results. Have you done much testing of the > change in your environment? > > -Chris > > [1] http://mail.openjdk.java.net/pipermail/nio-dev/2016-January/003509.html > [2] http://cr.openjdk.java.net/~martin/webrevs/openjdk9/ipv6-only/ > [3] https://bugs.openjdk.java.net/browse/JDK-8148424 > From chris.hegarty at oracle.com Tue May 24 18:59:01 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 24 May 2016 19:59:01 +0100 Subject: RFR 8136933: Additional tests for Solaris SO_FLOW_SLA socket option in JDK 9 In-Reply-To: <57447F8F.4000709@oracle.com> References: <573DE62C.7020300@oracle.com> <573DEF29.7090201@oracle.com> <573EE3F1.1000109@oracle.com> <573EFE15.2080102@oracle.com> <573F0B94.4020803@oracle.com> <573F0CBB.2060600@oracle.com> <3BF32E17-9F82-423C-8351-EF27CCF0393B@oracle.com> <57433182.2080902@oracle.com> <57447F8F.4000709@oracle.com> Message-ID: > On 24 May 2016, at 17:21, Svetlana Nikandrova wrote: > > I hate being annoying, but may be you can find another minute to review updated diff? This mainly look fine. Some comments: - The test will need to '@build jdk.testlibrary.*? to ensure that the library classes are compiled. Please verify that the test can run successfully, by itself, in a clean work directory. - You can initialize ?expectSupport' and make it final: private static final boolean expectSupport = checkExpectedOptionSupport(); - If you statically import SO_FLOW_SLA, then things will fit easier, e.g. import static jdk.net.ExtendedSocketOptions.SO_FLOW_SLA; ? if (s.supportedOptions().contains(SO_FLOW_SLA) != expectSupport) { ? and maybe drop the unnecessary braces. - Can you please revert the indentation on SocketFlow.create(), i.e. line up the dots -Chris. > Thank you, > Svetlana > > On 23.05.2016 19:36, Svetlana Nikandrova wrote: >> Alan, Chris, >> >> thank you for your comments. I've decided to do as Chris suggested and updated existing test test/jdk/net/Sockets/Test.java instead of creating a new one. >> Please see updated review: >> >> http://cr.openjdk.java.net/~snikandrova/8136933/webrev.03/ >> >> Thank you, >> Svetlana >> >> On 20.05.2016 18:19, Chris Hegarty wrote: >>>> On 20 May 2016, at 14:10, Alan Bateman wrote: >>>> >>>> On 20/05/2016 14:05, Svetlana Nikandrova wrote: >>>>> Alan, >>>>> >>>>> another test related to this option is on the same level (test/jdk/net/SocketFlow) >>> I added this recently, when working on a different issue, when I >>> noticed that there were no tests for the SocketFllow API, regardless >>> of the underlying system support. The test directory structure >>> matches the class package/name hierarchy. >>> >>>>> so I thought it's ok to maintain the same hierarchy. I can move test to test/jdk/net/Sockets/ExtendedSocketOptions/SO_FLOW_SLA or to test/jdk/net/Sockets, but in that case won't it be a little bit confusing? >>>>> >>>>> As for overlapping coverage: existing test silently exits if option is not in supported list while this one is focused on platform support check. >>>> I think it would be good to put all the tests in the same place, will make it easier for further maintenance in this area. >>> The proposed new test seems, somewhat, to be a replacement for >>> test/jdk/net/Sockets/Test.java, but it does not assert that if set >>> succeeds that get should return something useful? Also set >>> typically cannot succeed unless run with privileges. The test also >>> seems to focus on setting the option through the idk.net.Sockets API >>> rather than through the setOption of the socket types, any reason >>> for this? The jdk.net.Sockets API should be deprecated in 9, as >>> we have a standard replacement. >>> >>> When working in the area previously, I ran >>> test/jdk/net/Sockets/Test.java manually and examined the output >>> to determine that the option was being set correctly. >>> >>> It this test is merely to check that the option is supported on >>> S 11.2 +, then maybe that could be added to the existing >>> test/jdk/net/Sockets/Test.java ? >>> >>> -Chris. >> > From christoph.langer at sap.com Tue May 24 20:21:40 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 24 May 2016 20:21:40 +0000 Subject: JDK-8148424 Support IPv6-only Unix environments In-Reply-To: <02A5EAA0-C1AB-47C3-8D06-7DA16EC5458E@oracle.com> References: <02A5EAA0-C1AB-47C3-8D06-7DA16EC5458E@oracle.com> Message-ID: Hi, to me the changes look good. I'll take the patch into my queue and do some testing on AIX. Best regards Christoph > -----Original Message----- > From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of Chris > Hegarty > Sent: Donnerstag, 12. Mai 2016 17:32 > To: Martin Buchholz ; net-dev at openjdk.java.net >> > OpenJDK Network Dev list > Subject: JDK-8148424 Support IPv6-only Unix environments > > Martin, > > Promoted by some other changes that are going on, I stumbled > across your proposal for 8148424: "Support IPv6-only Unix > environments" [1][2][3]. > > I think the changes are good. I rebased them against the latest > source in jdk9/dev. > > http://cr.openjdk.java.net/~chegar/8148424/ > > I put the changes through our build and test system, and there > are no surprising results. Have you done much testing of the > change in your environment? > > -Chris > > [1] http://mail.openjdk.java.net/pipermail/nio-dev/2016-January/003509.html > [2] http://cr.openjdk.java.net/~martin/webrevs/openjdk9/ipv6-only/ > [3] https://bugs.openjdk.java.net/browse/JDK-8148424 From chris.hegarty at oracle.com Wed May 25 09:50:16 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 25 May 2016 10:50:16 +0100 Subject: RFR 8157811 [9] Additional minor fixes and cleanups in NetworkInterface.c Message-ID: As a follow up to JDK-8156521, and when comparing against the version of this file in jdk8u-dev a few minor issues were noticed. There is a free of a memory structure that was missed somehow in the 9 version of this file ( it is already in the 8 version ). The remaining few changes are just some minor cleanup. http://cr.openjdk.java.net/~chegar/8157811/ https://bugs.openjdk.java.net/browse/JDK-8157811 -Chris. From Alan.Bateman at oracle.com Wed May 25 09:52:26 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 25 May 2016 10:52:26 +0100 Subject: RFR 8157811 [9] Additional minor fixes and cleanups in NetworkInterface.c In-Reply-To: References: Message-ID: <574575DA.8060100@oracle.com> On 25/05/2016 10:50, Chris Hegarty wrote: > As a follow up to JDK-8156521, and when comparing against the > version of this file in jdk8u-dev a few minor issues were noticed. > > There is a free of a memory structure that was missed somehow > in the 9 version of this file ( it is already in the 8 version ). The > remaining few changes are just some minor cleanup. > > http://cr.openjdk.java.net/~chegar/8157811/ > https://bugs.openjdk.java.net/browse/JDK-8157811 > Looks fine. From mark.sheppard at oracle.com Wed May 25 11:46:19 2016 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Wed, 25 May 2016 12:46:19 +0100 Subject: RFR 8157811 [9] Additional minor fixes and cleanups in NetworkInterface.c In-Reply-To: References: Message-ID: <5a3a0589-4da0-07f9-d4e1-7daea74b5494@oracle.com> Hi Chris, the fix for 8068028 was marked 9-na for some reason, as such afaik the changes were not propagated to JDK9, which changed its src tree structure at that time (i think, jdk8 were on solaris files), parfait may not have highlighted them in that context afaik the other changes in that set were not applied (Inet6AddressImpl.c, net_util_md.c) . regards Mark On 25/05/2016 10:50, Chris Hegarty wrote: > As a follow up to JDK-8156521, and when comparing against the > version of this file in jdk8u-dev a few minor issues were noticed. > > There is a free of a memory structure that was missed somehow > in the 9 version of this file ( it is already in the 8 version ). The > remaining few changes are just some minor cleanup. > > http://cr.openjdk.java.net/~chegar/8157811/ > https://bugs.openjdk.java.net/browse/JDK-8157811 > > -Chris. From christoph.langer at sap.com Wed May 25 12:59:30 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 25 May 2016 12:59:30 +0000 Subject: RFR 8157811 [9] Additional minor fixes and cleanups in NetworkInterface.c In-Reply-To: References: Message-ID: Hi Chris, looks nice, I had seen some of these places, too. Here is another one which you could add: --- a/src/java.base/unix/native/libnet/NetworkInterface.c Tue May 24 10:14:41 2016 -0700 +++ b/src/java.base/unix/native/libnet/NetworkInterface.c Wed May 25 14:56:31 2016 +0200 @@ -1829,7 +1829,7 @@ strncpy(if2.lifr_name, ifname, sizeof(if2.lifr_name) - 1); if (ioctl(sock, SIOCGLIFFLAGS, (char *)&if2) < 0) { - return -1; + return -1; } *flags = if2.lifr_flags; Best regards Christoph > -----Original Message----- > From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of Chris > Hegarty > Sent: Mittwoch, 25. Mai 2016 11:50 > To: OpenJDK Network Dev list > Subject: RFR 8157811 [9] Additional minor fixes and cleanups in > NetworkInterface.c > > As a follow up to JDK-8156521, and when comparing against the > version of this file in jdk8u-dev a few minor issues were noticed. > > There is a free of a memory structure that was missed somehow > in the 9 version of this file ( it is already in the 8 version ). The > remaining few changes are just some minor cleanup. > > http://cr.openjdk.java.net/~chegar/8157811/ > https://bugs.openjdk.java.net/browse/JDK-8157811 > > -Chris. From svetlana.nikandrova at oracle.com Wed May 25 13:04:16 2016 From: svetlana.nikandrova at oracle.com (Svetlana Nikandrova) Date: Wed, 25 May 2016 16:04:16 +0300 Subject: RFR 8136933: Additional tests for Solaris SO_FLOW_SLA socket option in JDK 9 In-Reply-To: References: <573DE62C.7020300@oracle.com> <573DEF29.7090201@oracle.com> <573EE3F1.1000109@oracle.com> <573EFE15.2080102@oracle.com> <573F0B94.4020803@oracle.com> <573F0CBB.2060600@oracle.com> <3BF32E17-9F82-423C-8351-EF27CCF0393B@oracle.com> <57433182.2080902@oracle.com> <57447F8F.4000709@oracle.com> Message-ID: <5745A2D0.5060907@oracle.com> Hi Chris, thank you for your comments. Please see updated review. (I left braces in one line "if" blocks, hope it wasn't strong objection) http://cr.openjdk.java.net/~snikandrova/8136933/webrev.04/ Tested as standalone 1 test manual run and with JPRT. Thank you, Svetlana On 24.05.2016 21:59, Chris Hegarty wrote: >> On 24 May 2016, at 17:21, Svetlana Nikandrova wrote: >> >> I hate being annoying, but may be you can find another minute to review updated diff? > This mainly look fine. Some comments: > > - The test will need to '@build jdk.testlibrary.*? to ensure that the library classes > are compiled. Please verify that the test can run successfully, by itself, in a > clean work directory. > > - You can initialize ?expectSupport' and make it final: > private static final boolean expectSupport = checkExpectedOptionSupport(); > > - If you statically import SO_FLOW_SLA, then things will fit easier, e.g. > > import static jdk.net.ExtendedSocketOptions.SO_FLOW_SLA; > ? > if (s.supportedOptions().contains(SO_FLOW_SLA) != expectSupport) { > > ? and maybe drop the unnecessary braces. > > - Can you please revert the indentation on SocketFlow.create(), > i.e. line up the dots > > -Chris. > >> Thank you, >> Svetlana >> >> On 23.05.2016 19:36, Svetlana Nikandrova wrote: >>> Alan, Chris, >>> >>> thank you for your comments. I've decided to do as Chris suggested and updated existing test test/jdk/net/Sockets/Test.java instead of creating a new one. >>> Please see updated review: >>> >>> http://cr.openjdk.java.net/~snikandrova/8136933/webrev.03/ >>> >>> Thank you, >>> Svetlana >>> >>> On 20.05.2016 18:19, Chris Hegarty wrote: >>>>> On 20 May 2016, at 14:10, Alan Bateman wrote: >>>>> >>>>> On 20/05/2016 14:05, Svetlana Nikandrova wrote: >>>>>> Alan, >>>>>> >>>>>> another test related to this option is on the same level (test/jdk/net/SocketFlow) >>>> I added this recently, when working on a different issue, when I >>>> noticed that there were no tests for the SocketFllow API, regardless >>>> of the underlying system support. The test directory structure >>>> matches the class package/name hierarchy. >>>> >>>>>> so I thought it's ok to maintain the same hierarchy. I can move test to test/jdk/net/Sockets/ExtendedSocketOptions/SO_FLOW_SLA or to test/jdk/net/Sockets, but in that case won't it be a little bit confusing? >>>>>> >>>>>> As for overlapping coverage: existing test silently exits if option is not in supported list while this one is focused on platform support check. >>>>> I think it would be good to put all the tests in the same place, will make it easier for further maintenance in this area. >>>> The proposed new test seems, somewhat, to be a replacement for >>>> test/jdk/net/Sockets/Test.java, but it does not assert that if set >>>> succeeds that get should return something useful? Also set >>>> typically cannot succeed unless run with privileges. The test also >>>> seems to focus on setting the option through the idk.net.Sockets API >>>> rather than through the setOption of the socket types, any reason >>>> for this? The jdk.net.Sockets API should be deprecated in 9, as >>>> we have a standard replacement. >>>> >>>> When working in the area previously, I ran >>>> test/jdk/net/Sockets/Test.java manually and examined the output >>>> to determine that the option was being set correctly. >>>> >>>> It this test is merely to check that the option is supported on >>>> S 11.2 +, then maybe that could be added to the existing >>>> test/jdk/net/Sockets/Test.java ? >>>> >>>> -Chris. From chris.hegarty at oracle.com Wed May 25 13:08:39 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 25 May 2016 14:08:39 +0100 Subject: RFR 8136933: Additional tests for Solaris SO_FLOW_SLA socket option in JDK 9 In-Reply-To: <5745A2D0.5060907@oracle.com> References: <573DE62C.7020300@oracle.com> <573DEF29.7090201@oracle.com> <573EE3F1.1000109@oracle.com> <573EFE15.2080102@oracle.com> <573F0B94.4020803@oracle.com> <573F0CBB.2060600@oracle.com> <3BF32E17-9F82-423C-8351-EF27CCF0393B@oracle.com> <57433182.2080902@oracle.com> <57447F8F.4000709@oracle.com> <5745A2D0.5060907@oracle.com> Message-ID: <9824329C-9421-4A2D-9B43-FB91A5C61456@oracle.com> On 25 May 2016, at 14:04, Svetlana Nikandrova wrote: > > Hi Chris, > > thank you for your comments. Please see updated review. (I left braces in one line "if" blocks, hope it wasn't strong objection) > > http://cr.openjdk.java.net/~snikandrova/8136933/webrev.04/ I think this is fine. >> - Can you please revert the indentation on SocketFlow.create(), >> i.e. line up the dots Trivially, before you push, just revert this to the way it was, dots lined up vertically. no need to regenerate the webrev. -Chris. From svetlana.nikandrova at oracle.com Wed May 25 13:18:45 2016 From: svetlana.nikandrova at oracle.com (Svetlana Nikandrova) Date: Wed, 25 May 2016 16:18:45 +0300 Subject: RFR 8136933: Additional tests for Solaris SO_FLOW_SLA socket option in JDK 9 In-Reply-To: <9824329C-9421-4A2D-9B43-FB91A5C61456@oracle.com> References: <573DE62C.7020300@oracle.com> <573DEF29.7090201@oracle.com> <573EE3F1.1000109@oracle.com> <573EFE15.2080102@oracle.com> <573F0B94.4020803@oracle.com> <573F0CBB.2060600@oracle.com> <3BF32E17-9F82-423C-8351-EF27CCF0393B@oracle.com> <57433182.2080902@oracle.com> <57447F8F.4000709@oracle.com> <5745A2D0.5060907@oracle.com> <9824329C-9421-4A2D-9B43-FB91A5C61456@oracle.com> Message-ID: <5745A635.2080901@oracle.com> Thank you, Chris! On 25.05.2016 16:08, Chris Hegarty wrote: > On 25 May 2016, at 14:04, Svetlana Nikandrova wrote: >> Hi Chris, >> >> thank you for your comments. Please see updated review. (I left braces in one line "if" blocks, hope it wasn't strong objection) >> >> http://cr.openjdk.java.net/~snikandrova/8136933/webrev.04/ > I think this is fine. > > >>> - Can you please revert the indentation on SocketFlow.create(), >>> i.e. line up the dots > Trivially, before you push, just revert this to the way it was, dots > lined up vertically. no need to regenerate the webrev. > > -Chris. > From chris.hegarty at oracle.com Wed May 25 13:22:06 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 25 May 2016 14:22:06 +0100 Subject: RFR 8157811 [9] Additional minor fixes and cleanups in Networking native code In-Reply-To: References: Message-ID: Thanks. I included it, though it may not show in the webrev ( white space change ) I generalise the issue to cover a few other minor issues. Webrev updated in-place: http://cr.openjdk.java.net/~chegar/8157811/ -Chris. > On 25 May 2016, at 13:59, Langer, Christoph wrote: > > Hi Chris, > > looks nice, I had seen some of these places, too. > > Here is another one which you could add: > > --- a/src/java.base/unix/native/libnet/NetworkInterface.c Tue May 24 10:14:41 2016 -0700 > +++ b/src/java.base/unix/native/libnet/NetworkInterface.c Wed May 25 14:56:31 2016 +0200 > @@ -1829,7 +1829,7 @@ > strncpy(if2.lifr_name, ifname, sizeof(if2.lifr_name) - 1); > > if (ioctl(sock, SIOCGLIFFLAGS, (char *)&if2) < 0) { > - return -1; > + return -1; > } > > *flags = if2.lifr_flags; > > Best regards > Christoph > >> -----Original Message----- >> From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of Chris >> Hegarty >> Sent: Mittwoch, 25. Mai 2016 11:50 >> To: OpenJDK Network Dev list >> Subject: RFR 8157811 [9] Additional minor fixes and cleanups in >> NetworkInterface.c >> >> As a follow up to JDK-8156521, and when comparing against the >> version of this file in jdk8u-dev a few minor issues were noticed. >> >> There is a free of a memory structure that was missed somehow >> in the 9 version of this file ( it is already in the 8 version ). The >> remaining few changes are just some minor cleanup. >> >> http://cr.openjdk.java.net/~chegar/8157811/ >> https://bugs.openjdk.java.net/browse/JDK-8157811 >> >> -Chris. From dmitry.samersoff at oracle.com Wed May 25 13:29:34 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 25 May 2016 16:29:34 +0300 Subject: RFR 8157811 [9] Additional minor fixes and cleanups in Networking native code In-Reply-To: References: Message-ID: <5745A8BE.9070204@oracle.com> Chris, Looks good for me! On 2016-05-25 16:22, Chris Hegarty wrote: > Thanks. I included it, though it may not show in the webrev ( white space change ) > > I generalise the issue to cover a few other minor issues. > > Webrev updated in-place: > http://cr.openjdk.java.net/~chegar/8157811/ > > -Chris. > >> On 25 May 2016, at 13:59, Langer, Christoph wrote: >> >> Hi Chris, >> >> looks nice, I had seen some of these places, too. >> >> Here is another one which you could add: >> >> --- a/src/java.base/unix/native/libnet/NetworkInterface.c Tue May 24 10:14:41 2016 -0700 >> +++ b/src/java.base/unix/native/libnet/NetworkInterface.c Wed May 25 14:56:31 2016 +0200 >> @@ -1829,7 +1829,7 @@ >> strncpy(if2.lifr_name, ifname, sizeof(if2.lifr_name) - 1); >> >> if (ioctl(sock, SIOCGLIFFLAGS, (char *)&if2) < 0) { >> - return -1; >> + return -1; >> } >> >> *flags = if2.lifr_flags; >> >> Best regards >> Christoph >> >>> -----Original Message----- >>> From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of Chris >>> Hegarty >>> Sent: Mittwoch, 25. Mai 2016 11:50 >>> To: OpenJDK Network Dev list >>> Subject: RFR 8157811 [9] Additional minor fixes and cleanups in >>> NetworkInterface.c >>> >>> As a follow up to JDK-8156521, and when comparing against the >>> version of this file in jdk8u-dev a few minor issues were noticed. >>> >>> There is a free of a memory structure that was missed somehow >>> in the 9 version of this file ( it is already in the 8 version ). The >>> remaining few changes are just some minor cleanup. >>> >>> http://cr.openjdk.java.net/~chegar/8157811/ >>> https://bugs.openjdk.java.net/browse/JDK-8157811 >>> >>> -Chris. > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From doychin at dsoft-bg.com Thu May 26 12:46:47 2016 From: doychin at dsoft-bg.com (Doychin Bondzhev) Date: Thu, 26 May 2016 15:46:47 +0300 Subject: Reminder about reported problem in NetworkInterface.c In-Reply-To: References: <57345B85.6040608@oracle.com> Message-ID: Hi, I have my signed Oca processed. I hope now we can continue with proposed patch? On May 12, 2016 14:18, "Ivan St. Ivanov" wrote: > Hello Alan, > > If that is the showstopper for moving this change forward, Doychin is part > of the Bulgarian JUG. Which has signed the OCA. I talked to him and he is > fine to let his change pass through JUG's account. > > Regards, > Ivan > On May 12, 2016 13:32, "Alan Bateman" wrote: > >> >> >> On 12/05/2016 11:25, Langer, Christoph wrote: >> >>> Hi Doychin, >>> >>> thanks for pointing me to this. I was already looking at that part of >>> the code and know about some gaps. So I'll take this item and open a bug >>> and work on integrating the proposed change. >>> >>> >>> I don't see Doychin on the of OCA signatories so I don't think we can >> accept the contribution without getting that sorted out. It might be that >> he is is listed with a different name or a company name of course. >> >> Creating a bug and fixing it should be fine of course. >> >> -Alan >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Thu May 26 12:57:58 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 26 May 2016 13:57:58 +0100 Subject: Reminder about reported problem in NetworkInterface.c In-Reply-To: References: <57345B85.6040608@oracle.com> Message-ID: > On 26 May 2016, at 13:46, Doychin Bondzhev wrote: > > Hi, I have my signed Oca processed. I hope now we can continue with proposed patch? I cannot find you on http://www.oracle.com/technetwork/community/oca-486395.html#list Please confirm your that you are on this list. Chris. From chris.hegarty at oracle.com Thu May 26 13:07:31 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 26 May 2016 14:07:31 +0100 Subject: Reminder about reported problem in NetworkInterface.c In-Reply-To: References: <57345B85.6040608@oracle.com> Message-ID: <8C9DF247-2935-4EDF-885E-2F29C5921E9B@oracle.com> > On 26 May 2016, at 13:57, Chris Hegarty wrote: > > >> On 26 May 2016, at 13:46, Doychin Bondzhev wrote: >> >> Hi, I have my signed Oca processed. I hope now we can continue with proposed patch? > > I cannot find you on http://www.oracle.com/technetwork/community/oca-486395.html#list > > Please confirm your that you are on this list. I have been assured that this has been done, and that you name will appear imminently. Please post your patch to the list and I will take a look. Thanks, -Chris. From chris.hegarty at oracle.com Thu May 26 13:33:06 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 26 May 2016 14:33:06 +0100 Subject: RFR [9] 8085785: sun/net/www/protocol/http/ZoneId.java timeout intermittently Message-ID: ZoneId is attempting to verify the 'Host' header set by the HttpURLConnection implementation when given an IPv6 literal containing a scope id. It does so by iterating the network interfaces on the machine attempting to find one that is suitable to use as the listening interface for a temporary test HTTP sever. Then it connects to it, and verifies the value of the 'Host' header. This is problematic as some interfaces like teredo on Windows, or awdl on Mac, are not suitable. Rather than all this, the test can use the IPv6 loopback address, which can contain a scope id, if retrieved from the NetworkInterface API. http://cr.openjdk.java.net/~chegar/8085785/ https://bugs.openjdk.java.net/browse/JDK-8085785 -Chris. From doychin at dsoft-bg.com Thu May 26 14:04:22 2016 From: doychin at dsoft-bg.com (Doychin Bondzhev) Date: Thu, 26 May 2016 17:04:22 +0300 Subject: Reminder about reported problem in NetworkInterface.c In-Reply-To: <8C9DF247-2935-4EDF-885E-2F29C5921E9B@oracle.com> References: <57345B85.6040608@oracle.com> <8C9DF247-2935-4EDF-885E-2F29C5921E9B@oracle.com> Message-ID: Hi, Here is a link to the original message I send in 2015 whit deception and link to the patch: http://mail.openjdk.java.net/pipermail/net-dev/2015-January/008829.html The patch is based on the NetworkInterface.c code at that time. If it is needed I can update it against current code. Have a nice day, Doychin Bondzhev On Thu, May 26, 2016 at 4:07 PM, Chris Hegarty wrote: > > > On 26 May 2016, at 13:57, Chris Hegarty > wrote: > > > > > >> On 26 May 2016, at 13:46, Doychin Bondzhev > wrote: > >> > >> Hi, I have my signed Oca processed. I hope now we can continue with > proposed patch? > > > > I cannot find you on > http://www.oracle.com/technetwork/community/oca-486395.html#list > > > > Please confirm your that you are on this list. > > I have been assured that this has been done, and that you name will appear > imminently. > > Please post your patch to the list and I will take a look. > > Thanks, > -Chris. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Thu May 26 17:21:49 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 26 May 2016 18:21:49 +0100 Subject: Reminder about reported problem in NetworkInterface.c In-Reply-To: References: <57345B85.6040608@oracle.com> <8C9DF247-2935-4EDF-885E-2F29C5921E9B@oracle.com> Message-ID: <6B9B23B9-21F4-48F1-BEC1-EC3F129A15D2@oracle.com> > On 26 May 2016, at 15:04, Doychin Bondzhev wrote: > > Hi, > > Here is a link to the original message I send in 2015 whit deception and link to the patch: > > http://mail.openjdk.java.net/pipermail/net-dev/2015-January/008829.html > > The patch is based on the NetworkInterface.c code at that time. > > If it is needed I can update it against current code. Yes, please. And can you please post the patch to this mailing list. I?m loath to go off openjdk infrastructure. -Chris. > Have a nice day, > Doychin Bondzhev > > On Thu, May 26, 2016 at 4:07 PM, Chris Hegarty wrote: > > > On 26 May 2016, at 13:57, Chris Hegarty wrote: > > > > > >> On 26 May 2016, at 13:46, Doychin Bondzhev wrote: > >> > >> Hi, I have my signed Oca processed. I hope now we can continue with proposed patch? > > > > I cannot find you on http://www.oracle.com/technetwork/community/oca-486395.html#list > > > > Please confirm your that you are on this list. > > I have been assured that this has been done, and that you name will appear imminently. > > Please post your patch to the list and I will take a look. > > Thanks, > -Chris. > > From christoph.langer at sap.com Thu May 26 21:45:44 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 26 May 2016 21:45:44 +0000 Subject: Reminder about reported problem in NetworkInterface.c In-Reply-To: References: <57345B85.6040608@oracle.com> <8C9DF247-2935-4EDF-885E-2F29C5921E9B@oracle.com> Message-ID: Hi Doychin, I think your issue/fix proposal is good. As I?m currently working on the addif function and planning some change there, firstly motivated by AIX, I could work your suggestions into my upcoming fix. If it can wait another one or two weeks I?d even love to do it. But feel free to rebase your change and go for contribution if you can?t wait. Then I?ll have to rebase my stuff eventually? Best regards Christoph From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of Doychin Bondzhev Sent: Donnerstag, 26. Mai 2016 16:04 To: Chris Hegarty ; net-dev at openjdk.java.net Subject: Re: Reminder about reported problem in NetworkInterface.c Hi, Here is a link to the original message I send in 2015 whit deception and link to the patch: http://mail.openjdk.java.net/pipermail/net-dev/2015-January/008829.html The patch is based on the NetworkInterface.c code at that time. If it is needed I can update it against current code. Have a nice day, Doychin Bondzhev On Thu, May 26, 2016 at 4:07 PM, Chris Hegarty > wrote: > On 26 May 2016, at 13:57, Chris Hegarty > wrote: > > >> On 26 May 2016, at 13:46, Doychin Bondzhev > wrote: >> >> Hi, I have my signed Oca processed. I hope now we can continue with proposed patch? > > I cannot find you on http://www.oracle.com/technetwork/community/oca-486395.html#list > > Please confirm your that you are on this list. I have been assured that this has been done, and that you name will appear imminently. Please post your patch to the list and I will take a look. Thanks, -Chris. -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Fri May 27 08:29:34 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 27 May 2016 08:29:34 +0000 Subject: RFR 8158023: SocketExceptions contain too little information sometimes Message-ID: Hi all, please review the following change: Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8158023.1/ Bug: https://bugs.openjdk.java.net/browse/JDK-8158023 During error analysis I stumbled over a place where I encountered a SocketException which was thrown along with some strerror information as message. I found it hard to find the originating code spot with that information. So I looked at the places where we throw exceptions, namely JNU_Throw... and NET_Throw... functions and came up with the following enhancement: - NET_ThrowByNameWithLastError can go completely as it does not provide any benefit over JNU_ThrowByNameWithLastError. - JNU_ThrowByNameWithLastError can be cleaned up. - I added JNU_ThrowByNameWithMessageAndLastError to print out a string like message + ": " + last error. - I went over all places where NET_ThrowByNameWithLastError is used and replaced it appropriately. Do you think this change is desirable/possible? Though it's mainly a net topic, I'm posting it to nio-dev and core-libs-dev as well as JNU_Throw... code affects all. Best regards Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.gerasimov at oracle.com Sun May 29 18:08:51 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Sun, 29 May 2016 21:08:51 +0300 Subject: [8u-dev] Request for Review & Approval to backport: 8073542: File Leak in jdk/src/java/base/unix/native/libnet/PlainDatagramSocketImpl.c In-Reply-To: <8d0c138a-4326-fb30-5628-55a3947a6789@oracle.com> References: <8d0c138a-4326-fb30-5628-55a3947a6789@oracle.com> Message-ID: As this has to be re-reviewed, sending the request to net-dev list as well. On 27.05.2016 16:46, Ivan Gerasimov wrote: > Hello! > > > I'd like to backport the fix to jdk8u-dev. > > The fix had to be slightly adjusted due to the different way the error > messages are retrieved in jdk8. > > Here's the webrev with modified fix: > http://cr.openjdk.java.net/~igerasim/8073542/00/webrev/ > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8073542 > Jdk9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/bb6e5a409fef > Jdk9 review: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035223.html > > With kind regards, Ivan From doychin at dsoft-bg.com Sun May 29 20:30:37 2016 From: doychin at dsoft-bg.com (Doychin Bondzhev) Date: Sun, 29 May 2016 23:30:37 +0300 Subject: Reminder about reported problem in NetworkInterface.c In-Reply-To: References: <57345B85.6040608@oracle.com> <8C9DF247-2935-4EDF-885E-2F29C5921E9B@oracle.com> Message-ID: <9b47b3e5-af4c-75a8-4ec0-6bc1761b9646@dsoft-bg.com> Hi guys, here is an updated webrev against current NetworkInterface.c http://downloads.dsoft-bg.com/networkInterface/webrev/ -- Doychin Bondzhev dSoft-Bulgaria Ltd. PowerPro - billing & provisioning solution for Service providers PowerStor - Warehouse & POS http://www.dsoft-bg.com/ Mobile: +359888243116 -------------- next part -------------- A non-text attachment was scrubbed... Name: doychin.vcf Type: text/x-vcard Size: 268 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5944 bytes Desc: S/MIME Cryptographic Signature URL: From felix.yang at oracle.com Mon May 30 07:18:24 2016 From: felix.yang at oracle.com (Felix Yang) Date: Mon, 30 May 2016 15:18:24 +0800 Subject: RFR 8157816, Mark 4 httpclient tests as intermittently failing Message-ID: Hi all, please review the change to mark following tests with keyword 'intermittent'. These tests have been observed to fail intermittently for a while. test/java/net/httpclient/SplitResponse.java test/java/net/httpclient/http2/BasicTest.java test/java/net/httpclient/http2/ErrorTest.java test/java/net/httpclient/http2/TLSConnection.java Bug: https://bugs.openjdk.java.net/browse/JDK-8157816 Webrev: http://cr.openjdk.java.net/~xiaofeya/8157816/webrev.00/ Thanks, Felix Also attached the diff: diff -r ee29aaab5889 test/java/net/httpclient/SplitResponse.java --- a/test/java/net/httpclient/SplitResponse.java Mon May 30 14:58:59 2016 +0900 +++ b/test/java/net/httpclient/SplitResponse.java Sun May 29 23:49:16 2016 -0700 @@ -33,6 +33,7 @@ /** * @test * @bug 8087112 + * @key intermittent * @build Server * @run main/othervm -Djava.net.HttpClient.log=all SplitResponse */ diff -r ee29aaab5889 test/java/net/httpclient/http2/BasicTest.java --- a/test/java/net/httpclient/http2/BasicTest.java Mon May 30 14:58:59 2016 +0900 +++ b/test/java/net/httpclient/http2/BasicTest.java Sun May 29 23:49:16 2016 -0700 @@ -24,6 +24,7 @@ /* * @test * @bug 8087112 + * @key intermittent * @library /lib/testlibrary * @build jdk.testlibrary.SimpleSSLContext * @modules java.httpclient diff -r ee29aaab5889 test/java/net/httpclient/http2/ErrorTest.java --- a/test/java/net/httpclient/http2/ErrorTest.java Mon May 30 14:58:59 2016 +0900 +++ b/test/java/net/httpclient/http2/ErrorTest.java Sun May 29 23:49:16 2016 -0700 @@ -24,6 +24,7 @@ /* * @test * @bug 8157105 + * @key intermittent * @library /lib/testlibrary * @build jdk.testlibrary.SimpleSSLContext * @modules java.httpclient diff -r ee29aaab5889 test/java/net/httpclient/http2/TLSConnection.java --- a/test/java/net/httpclient/http2/TLSConnection.java Mon May 30 14:58:59 2016 +0900 +++ b/test/java/net/httpclient/http2/TLSConnection.java Sun May 29 23:49:16 2016 -0700 @@ -39,6 +39,7 @@ /* * @test * @bug 8150769 8157107 + * @key intermittent * @summary Checks that SSL parameters can be set for HTTP/2 connection * @modules java.httpclient * @compile/module=java.httpclient java/net/http/Http2Handler.java From chris.hegarty at oracle.com Mon May 30 09:13:48 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 30 May 2016 10:13:48 +0100 Subject: RFR 8157816, Mark 4 httpclient tests as intermittently failing In-Reply-To: References: Message-ID: <574C044C.8030807@oracle.com> This is sad, but I agree. Reviewed. -Chris. On 30/05/16 08:18, Felix Yang wrote: > Hi all, > please review the change to mark following tests with keyword > 'intermittent'. These tests have been observed to fail intermittently > for a while. > test/java/net/httpclient/SplitResponse.java > test/java/net/httpclient/http2/BasicTest.java > test/java/net/httpclient/http2/ErrorTest.java > test/java/net/httpclient/http2/TLSConnection.java > > Bug: https://bugs.openjdk.java.net/browse/JDK-8157816 > Webrev: http://cr.openjdk.java.net/~xiaofeya/8157816/webrev.00/ > > Thanks, > Felix > > Also attached the diff: > > diff -r ee29aaab5889 test/java/net/httpclient/SplitResponse.java > --- a/test/java/net/httpclient/SplitResponse.java Mon May 30 > 14:58:59 2016 +0900 > +++ b/test/java/net/httpclient/SplitResponse.java Sun May 29 > 23:49:16 2016 -0700 > @@ -33,6 +33,7 @@ > /** > * @test > * @bug 8087112 > + * @key intermittent > * @build Server > * @run main/othervm -Djava.net.HttpClient.log=all SplitResponse > */ > diff -r ee29aaab5889 test/java/net/httpclient/http2/BasicTest.java > --- a/test/java/net/httpclient/http2/BasicTest.java Mon May 30 > 14:58:59 2016 +0900 > +++ b/test/java/net/httpclient/http2/BasicTest.java Sun May 29 > 23:49:16 2016 -0700 > @@ -24,6 +24,7 @@ > /* > * @test > * @bug 8087112 > + * @key intermittent > * @library /lib/testlibrary > * @build jdk.testlibrary.SimpleSSLContext > * @modules java.httpclient > diff -r ee29aaab5889 test/java/net/httpclient/http2/ErrorTest.java > --- a/test/java/net/httpclient/http2/ErrorTest.java Mon May 30 > 14:58:59 2016 +0900 > +++ b/test/java/net/httpclient/http2/ErrorTest.java Sun May 29 > 23:49:16 2016 -0700 > @@ -24,6 +24,7 @@ > /* > * @test > * @bug 8157105 > + * @key intermittent > * @library /lib/testlibrary > * @build jdk.testlibrary.SimpleSSLContext > * @modules java.httpclient > diff -r ee29aaab5889 test/java/net/httpclient/http2/TLSConnection.java > --- a/test/java/net/httpclient/http2/TLSConnection.java Mon May 30 > 14:58:59 2016 +0900 > +++ b/test/java/net/httpclient/http2/TLSConnection.java Sun May 29 > 23:49:16 2016 -0700 > @@ -39,6 +39,7 @@ > /* > * @test > * @bug 8150769 8157107 > + * @key intermittent > * @summary Checks that SSL parameters can be set for HTTP/2 connection > * @modules java.httpclient > * @compile/module=java.httpclient java/net/http/Http2Handler.java > From chris.hegarty at oracle.com Mon May 30 09:18:27 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 30 May 2016 10:18:27 +0100 Subject: Reminder about reported problem in NetworkInterface.c In-Reply-To: <9b47b3e5-af4c-75a8-4ec0-6bc1761b9646@dsoft-bg.com> References: <57345B85.6040608@oracle.com> <8C9DF247-2935-4EDF-885E-2F29C5921E9B@oracle.com> <9b47b3e5-af4c-75a8-4ec0-6bc1761b9646@dsoft-bg.com> Message-ID: <574C0563.20806@oracle.com> Doychin, Apologies, I am having issues accessing that URL, can you please post the output of 'hg diff' to this list, and I will examine your proposed patch. -Chris. On 29/05/16 21:30, Doychin Bondzhev wrote: > Hi guys, > > here is an updated webrev against current NetworkInterface.c > > http://downloads.dsoft-bg.com/networkInterface/webrev/ > From doychin at dsoft-bg.com Mon May 30 12:51:16 2016 From: doychin at dsoft-bg.com (Doychin Bondzhev) Date: Mon, 30 May 2016 15:51:16 +0300 Subject: Reminder about reported problem in NetworkInterface.c In-Reply-To: <574C0563.20806@oracle.com> References: <57345B85.6040608@oracle.com> <8C9DF247-2935-4EDF-885E-2F29C5921E9B@oracle.com> <9b47b3e5-af4c-75a8-4ec0-6bc1761b9646@dsoft-bg.com> <574C0563.20806@oracle.com> Message-ID: <4791e9da-ae4d-731c-054e-3fe700b04b80@dsoft-bg.com> Attached is the diff file -- Doychin Bondzhev dSoft-Bulgaria Ltd. PowerPro - billing & provisioning solution for Service providers PowerStor - Warehouse & POS http://www.dsoft-bg.com/ Mobile: +359888243116 -------------- next part -------------- A non-text attachment was scrubbed... Name: jdk.diff Type: text/x-patch Size: 7465 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: doychin.vcf Type: text/x-vcard Size: 268 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5944 bytes Desc: S/MIME Cryptographic Signature URL: From mark.sheppard at oracle.com Mon May 30 21:52:19 2016 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Mon, 30 May 2016 22:52:19 +0100 Subject: RFR [9] 8085785: sun/net/www/protocol/http/ZoneId.java timeout intermittently In-Reply-To: References: Message-ID: <6cb6ce51-4b90-8d44-bbe5-ff0b10da43c5@oracle.com> Hi Chris, this looks good ... so the server now listens on wildcard and the client uses IPv6 loopback as the destination address. The use of NO_PROXY, is good. I wouldn't have thought of that, and in the past, Tests have experienced firewall issues on linux and macos perviously without this setting. regards Mark On 26/05/2016 14:33, Chris Hegarty wrote: > ZoneId is attempting to verify the 'Host' header set by the HttpURLConnection implementation > when given an IPv6 literal containing a scope id. It does so by iterating the network interfaces > on the machine attempting to find one that is suitable to use as the listening interface for a > temporary test HTTP sever. Then it connects to it, and verifies the value of the 'Host' header. > > This is problematic as some interfaces like teredo on Windows, or awdl on Mac, are not > suitable. Rather than all this, the test can use the IPv6 loopback address, which can contain > a scope id, if retrieved from the NetworkInterface API. > > http://cr.openjdk.java.net/~chegar/8085785/ > https://bugs.openjdk.java.net/browse/JDK-8085785 > > -Chris. From sean.coffey at oracle.com Tue May 31 09:45:28 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 31 May 2016 10:45:28 +0100 Subject: RFR [9] 8085785: sun/net/www/protocol/http/ZoneId.java timeout intermittently In-Reply-To: <6cb6ce51-4b90-8d44-bbe5-ff0b10da43c5@oracle.com> References: <6cb6ce51-4b90-8d44-bbe5-ff0b10da43c5@oracle.com> Message-ID: Looks fine to me also Chris. Regards, Sean. On 30/05/2016 22:52, Mark Sheppard wrote: > Hi Chris, > this looks good ... so the server now listens on wildcard and the > client uses IPv6 loopback as the destination address. > The use of NO_PROXY, is good. I wouldn't have thought of that, and in > the past, Tests have experienced firewall issues on > linux and macos perviously without this setting. > > regards > Mark > > On 26/05/2016 14:33, Chris Hegarty wrote: >> ZoneId is attempting to verify the 'Host' header set by the >> HttpURLConnection implementation >> when given an IPv6 literal containing a scope id. It does so by >> iterating the network interfaces >> on the machine attempting to find one that is suitable to use as the >> listening interface for a >> temporary test HTTP sever. Then it connects to it, and verifies the >> value of the 'Host' header. >> >> This is problematic as some interfaces like teredo on Windows, or >> awdl on Mac, are not >> suitable. Rather than all this, the test can use the IPv6 loopback >> address, which can contain >> a scope id, if retrieved from the NetworkInterface API. >> >> http://cr.openjdk.java.net/~chegar/8085785/ >> https://bugs.openjdk.java.net/browse/JDK-8085785 >> >> -Chris. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pavel.rappo at oracle.com Tue May 31 17:25:59 2016 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Tue, 31 May 2016 18:25:59 +0100 Subject: RFR JDK-8156742: Miscellaneous WebSocket API improvements Message-ID: Hi, Could you please review the following change for JDK-8156742? http://cr.openjdk.java.net/~prappo/8156742/webrev.01/ This change addresses the first group of WebSocket API refinements and enhancements from [1]. 1. Change method `Builder#connectTimeout(long, TimeUnit)` to `Builder#connectTimeout(Duration)` Make use of convenience introduced with java.time API. The builder is not a performance-critical place, so there's no harm in constructing an object of `java.time.Duration` each time it's needed. Moreover, since 9, there's a bridge between TimeUnit and Duration: java.util.concurrent.TimeUnit.toChronoUnit 2. Change method `long WebSocket#request(long)` to `void WebSocket#request(long)` Otherwise a detail of implementation becomes a part of the spec. In this case it's not desirable, since we'll have to specify the behaviour in the corner case (long wrap) and force future implementations to maintain this abstraction. 3. Remove method `WebSocket#sendBinary(byte[], boolean)` This method provides not enough convenience to justify its existence. 4. Change type `CloseCode` for `CloseReason` that aggregates both status code and close reason. Current `Listener.onClose` looks ugly. It hides the otherwise explicit to all WebSocket users knowledge that 'reason' string can't go without the 'status code', i.e.: (statusCode reason?)? CloseReason types fuses both entities into a single type. As a bonus all knowledge about status code and reason string formats is now bound to a single place. 5. Specify `WebSocket#sendClose` idempotency Not producing IllegalStateException upon an attempt to close an already closed WebSocket seems to be a user-friendly solution. It's already an established practice in the JDK, e.g. java.nio.channels.SocketChannel.shutdownOutput 6. A number of miscellaneous editorial changes, missing copyright headers, tests. Thanks, -Pavel -------------------------------------------------------------------------------- [1] https://bugs.openjdk.java.net/browse/JDK-8155621 From simone.bordet at gmail.com Tue May 31 22:05:59 2016 From: simone.bordet at gmail.com (Simone Bordet) Date: Wed, 1 Jun 2016 00:05:59 +0200 Subject: RFR JDK-8156742: Miscellaneous WebSocket API improvements In-Reply-To: References: Message-ID: Pavel, On Tue, May 31, 2016 at 7:25 PM, Pavel Rappo wrote: > Hi, > > Could you please review the following change for JDK-8156742? > > http://cr.openjdk.java.net/~prappo/8156742/webrev.01/ Comments on the API only. Looks much cleaner, good job. I like WebSocket.request(long) being reinstated, and the Listener methods taking a WebSocket as first parameter, Builder.header() being sane :) Further comments: * What is interface Text for ? If it does perform a bytes-to-chars conversion, then offering asByteBuffer() can be easily done by the application. A websocket implementation must check that the incoming text bytes are indeed UTF-8. Doing the check is equivalent to creating the corresponding String, so I'm not sure Text is of any help. * CloseReason I would rename it to CloseInfo, as CloseReason hints to me of the reason only, not the code. I think this class exposes too many failure codes that applications *must not* be able to use. For example, 1002 is not something that the application can ever send, only the implementation can, and having a public API to create a 1002 CloseInfo is not something you I'd like to see exposed. Same goes with 1007, which the implementation must detect, not the application; etc. I would probably just leave CloseInfo.of(), with the current checks you are doing extended. * onClose() semantic. I am not sure why CloseInfo is wrapped with an Optional ? Can't the implementation just synthesize a (1005, "") instead and get rid of the Optional ? Also, I think it should return a CF, for the following reason. Notification of onClose() is a half-close. Applications are entitled to send data from within onClose(). For such reason, the implementation cannot send the response close frame just after the method returns. It should wait until the application has finished writing, and hence the need for the CF. * sendText(Stream message); I think it's too much for a utility method. It's a rare use case, I don't think it's worth it. Applications that wrap the default WebSocket object will have to implement it. ws.sendText(stream.collect(joining())) is equivalent and as short. If the goal was to send one frame per string, there is almost zero chance that the exact fragmentation is maintained at the server, so once again I don't see the reason for this method. * Extensions I don't recall if extensions have been ruled out ? Browsers seem to have settled at implementing permessage-deflate. Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz