Re: RFR[10]: 8185072 network006 times out in many configs in JDK10-hs nightly

> On 15 Sep 2017, at 10:29, vyom tewari wrote: > > Hi, > > Please review, small code change below. > > webrev: http://cr.openjdk.java.net/~vtewari/8185072/webrev0.0/index.html The changes look good to me Vyom. ( I only took a cursory look at the test changes )

Re: RFR 8187026/10, Remove intermittent key from java/net/httpclient/http2/BasicTest.java

> On 14 Sep 2017, at 07:48, Felix Yang wrote: > > Hi there, > >please review a minor patch to remove key intermittent. The original bug > has been resolved in JDK-8177935 and no intermittent failure observed since > there. > > Bug: > >

Re: [RFR] 8184328: JDK8u131 socketRead0 hang at SSL read

Xuelei, Without diving deeper into this issue, Rob’s suggested approach seems reasonable to me, and better than existing out-of-the-box behaviour. I’m not sure what issues you are thinking of, with using the read timeout in combination with a retry mechanism, in this manner? If the network is

Re: RFR[10]:8159526 Deprivilege jdk.httpserver

> On 12 Sep 2017, at 09:46, vyom tewari wrote: > > On Tuesday 12 September 2017 02:12 PM, Alan Bateman wrote: >> On 12/09/2017 09:06, vyom tewari wrote: >>> Hi, >>> >>> Please review the below code change. >>> >>> BugId: https://bugs.openjdk.java.net/browse/JDK-8159526

Re: RFR 8134989/10, java/net/MulticastSocket/TestInterfaces.java failed due to unexpected IP address

> On 4 Sep 2017, at 06:29, Felix Yang wrote: > > Hi Mark and Roger, > > thanks for the comments. Adjusted the test to just simply print > information for all network interfaces on failing. > > Webrev: > >

Re: [10] RFR 8187044: HttpClient ConnectionPool may spawn several concurrent CacheCleaner and prevent early GC of HttpClient.

On 31/08/17 16:07, Daniel Fuchs wrote: Hi, Please find below a small fix for: 8187044: HttpClient ConnectionPool may spawn several concurrent CacheCleaner and prevent early GC of HttpClient. https://bugs.openjdk.java.net/browse/JDK-8187044 webrev:

Re: [10] RFR: 8186930: Constant fold URI constants

> On 31 Aug 2017, at 16:26, Claes Redestad wrote: > > > On 2017-08-30 17:17, Alan Bateman wrote: >> I think it could be useful as someone reading the code isn't going to >> immediately know to jump to URI. > > Done:

Re: RFR 8184285: Buffer sizes of Flow based BodyProcessor API

Tobias, Your mail provoked me look further into the issue of memory usage in the implementation. I now see that there is certainly the possibility for an extreme amount of memory to be used in the pathological case. I filed an issue to track this ( it has more details ), and have a proposed

Re: RFR 8184285: Buffer sizes of Flow based BodyProcessor API

Tobias, Thank you for trying this out and giving such a detailed reply. Comments inline ... On 18 Aug 2017, at 18:45, Tobias Thierer wrote: Hi Michael & Chris - apologies for the slow follow-up. I couldn't get my IDE (IntelliJ) to accept a locally built OpenJDK 9 into

Re: [10] RFR: 8177935: java/net/httpclient/http2/FixedThreadPoolTest.java fails frequently

> On 16 Aug 2017, at 17:08, Daniel Fuchs wrote: > > Hi, > > Please find a small fix for: > > 8177935: java/net/httpclient/http2/FixedThreadPoolTest.java fails frequently > https://bugs.openjdk.java.net/browse/JDK-8177935 > > webrev: >

Re: RFR 8184285: Buffer sizes of Flow based BodyProcessor API

Tobias, Michael, I did a few rounds of iteration on this, that address Tobias’s comments ( modulo the variable buffer sizing, which we agreed to defer for now unless there is a compelling use case ). With this change, there is zero-copy of data. The composite container, List, is relatively

Re: [JDK 10] RFR: 8185852: HttpConnection should resolve addresses before SocketChannel.connect() is called

> On 4 Aug 2017, at 10:14, Daniel Fuchs wrote: > > Hi, > > Please find below a small fix for > 8185852: HttpConnection should resolve addresses before > SocketChannel.connect() is called > https://bugs.openjdk.java.net/browse/JDK-8185852 > >

Re: HTTP Client incubator API

Hi Tobias, > On 3 Jul 2017, at 23:48, Tobias Thierer wrote: > > Hi Michael, Chris, net-dev - > > the attached PDF contains some additional technical feedback on the API for > JEP-110 (HTTP/2 client) that is slated for inclusion as an incubator module > of OpenJDK 9. I

Re: RFR : 8182672: Java 8u121 on Linux intermittently returns null for MAC address

On 23/06/17 10:56, Seán Coffey wrote: Thanks to Christoph, Vyom and Mark for the reviews. I've improved the testcase as per feedback. Hope this meets all requests : http://cr.openjdk.java.net/~coffeys/webrev.8182672.jdk10.v2/webrev/ The change looks good. Sean and I did a live coding

Re: (9 test only) RFR: 8181867: [tests] Reorganize EchoHandlers

On 09/06/17 15:07, Daniel Fuchs wrote: .. http://cr.openjdk.java.net/~dfuchs/webrev_8181867/webrev.00/ This looks like a good clean up. Reviewed. -Chris.

Re: RFR 8181635/10, sun/net/www/protocol/jar/B6449504.java fails at Windows platform (after JDK-8181414)

> On 6 Jun 2017, at 05:52, Felix Yang wrote: > > Hi, > > please review the patch to make the test run with othervm mode. It has been > observed to be failing in agentvm mode, because Jar connection is not closed > in prior test. > > Bug:

Re: RFR 8166139/10, Refactor java/net shell cases to java

On 29/05/17 16:17, Felix Yang wrote: Hi Chris, please review the updated webrev below. Comments inline. http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.03/ Thanks Felix. .. 2) test/java/net/URLClassLoader/getresourceasstream/policy Please add a copyright/header. Checked

Re: RFR 8166139/10, Refactor java/net shell cases to java

Felix, Thanks for taking this one. A few comments: 1) test/java/net/URLConnection/6212146/TestDriver.java Please check indentation around L81: 80 Files.copy(testJar, ___targetDir.resolve(ARCHIVE_NAME), 81

Re: RFR 9: 8180303: Remove technote doc link from ProxySelector/B8035158.java test

On 12/05/17 17:24, Michael McMahon wrote: This is a trivial test change (in comments only) to remove a URL reference to a document whose location is different in the JDK 9 docs tree. The link is not needed in the test. So, it is removed.

Re: RFR: 8179559 Solaris MulticastSocket issues

> On 5 May 2017, at 18:36, Michael McMahon <michael.x.mcma...@oracle.com> wrote: > > > > On 05/05/2017, 18:30, Chris Hegarty wrote: >>> On 5 May 2017, at 18:29, Michael McMahon<michael.x.mcma...@oracle.com> >>> wrote: >>> ... >&

Re: RFR: 8179559 Solaris MulticastSocket issues

> On 5 May 2017, at 16:19, Michael McMahon wrote: > > Updated webrev at: http://cr.openjdk.java.net/~michaelm/8179559/webrev.2/ InetAddress.scope_id is optional ( 0 if unset ), should the code only use it if it is non-zero? -Chris.

Re: RFR: 8179559 Solaris MulticastSocket issues

> On 5 May 2017, at 10:23, Michael McMahon wrote: > > Could I get the following changed reviewed please? > > It's a fix for the two Solaris Multicast socket tests that fail always. > > http://cr.openjdk.java.net/~michaelm/8179559/webrev.1/ This looks ok to me

Re: RFR: JDK-7155591 - [macosx] regression test java/net/MulticastSocket/SetOutgoingIf.java fail

> On 4 May 2017, at 21:56, Mark Sheppard wrote: > > Hi, >please oblige and review the following change > http://cr.openjdk.java.net/~msheppar/7155591/webrev/ This is fine Mark. Alternatively, you could use the NetworkConfiguration probe, but I’m just happy to see

Re: RFR [9] 7155591: test/java/net/MulticastSocket/SetOutgoingIf.java fails on macOS

Ignore this. Mark has a review out to resolve this issue. http://mail.openjdk.java.net/pipermail/net-dev/2017-May/010765.html -Chris. > On 5 May 2017, at 08:58, Chris Hegarty <chris.hega...@oracle.com> wrote: > > This is a test-only change. > > This is one of the last

RFR [9] 7155591: test/java/net/MulticastSocket/SetOutgoingIf.java fails on macOS

This is a test-only change. This is one of the last remaining networking tests that fails when an Apple Peer-to-Peer interface is available on the host machine. The changes minimally update the test to use the new test library Network configuration probe ( centralises and filters platform

Re: RFR 8179602: Fix for JDK-8165437 is broken on 32-bit Linux

> On 4 May 2017, at 17:58, Michael McMahon wrote: > > Hi Vyom, > > As discussed, I think there are still some issues including on 32 bit Linux > and since we don't > have too many of those machines left to debug with, it's probably best to > back out the

Re: RFR: JDK-8179512 - Typo in HttpURLConnection documentation

Mark, The change looks ok to me. -Chris. On 02/05/17 14:51, Mark Sheppard wrote: Hi please oblige and review the minor change, to javadoc of HttpURLConnection, below which addresses the punctuation correction requested in https://bugs.openjdk.java.net/browse/JDK-8179512 regards Mark

Re: RFR 8175814: HttpClient protocol version needs unspecified value

On 28/04/17 11:24, Michael McMahon wrote: ... Ok, how about enable/disable Callback? I’m less sure what, if anything, AsyncConnection.unblock could be renamed to, since it has no knowledge of blocking or callbacks in the first place. It would have to be enableCallback() from above.

Re: RFR 8175814: HttpClient protocol version needs unspecified value

> On 27 Apr 2017, at 16:41, Michael McMahon > wrote: > > ... >> 4) AsyncConnection / Queue >> >> I find the term ‘block’ confusing here. It seems that the input channel, >> in the AsyncSSLDelegate implicitly puts itself into “blocking” mode >> when

Re: RFR 8175814: HttpClient protocol version needs unspecified value

> On 27 Apr 2017, at 10:18, Daniel Fuchs wrote: > > Hi Michael, > > On 26/04/2017 16:22, Michael McMahon wrote: >> Hi, >> >> This webrev has been updated with a number of additional changes since >> the first review. >> >> The latest webrev is at: >>

Re: RFR [9] 8179392: Fix warnings in the httpclient javadoc

> On 27 Apr 2017, at 11:56, Daniel Fuchs <daniel.fu...@oracle.com> wrote: > > Looks good Chris! > > Maybe the copyright year should be updated as well? Thanks for the review Daniel. I updated the copyright years before pushing. -Chris. > cheers, > > -- daniel &

RFR [9] 8179392: Fix warnings in the httpclient javadoc

A few @param and @return tags have missing descriptions. The description wording, in a few cases, has just been taken from sibling method descriptions ( nothing new here ). http://cr.openjdk.java.net/~chegar/8179392/ -Chris.

Re: JDK10 RFR: 8165437 Evaluate the use of gettimeofday in Networking code

> On 27 Apr 2017, at 05:15, Vyom Tewari wrote: > > Hi, > > please find the updated > webrev(http://cr.openjdk.java.net/~vtewari/8165437/webrev0.7/index.html). This looks ok to me Vyom, but I think you have misinterpreted my comment... >> ... >> 1)

Re: [JDK 10] RFR: 8179273: sun.net.httpserver.LeftOverInputStream should stop attempting to drain the stream when the server is stopped

> On 25 Apr 2017, at 14:48, Daniel Fuchs wrote: > > Hi, > > Please find below a fix for: > > 8179273: sun.net.httpserver.LeftOverInputStream should stop > attempting to drain the stream when the server is stopped >

Re: [PATCH] 8035653: jdk8u152-b01 windows crash on DatagramSocket.getLocalAddress

> On 24 Apr 2017, at 14:27, Langer, Christoph wrote: > > Hi Alex, > > to me your patch looks good. > > But since I'm not a JDK8 Reviewer, someone with this merits has to review it. > @Chris: May I ask you to have a look? >> ... >> >> [1]

Re: JDK10 RFR: 8165437 Evaluate the use of gettimeofday in Networking code

> On Tue, Apr 18, 2017 at 7:08 AM, Vyom Tewari wrote: > ... > > Thanks for review, please find the updated > webrev(http://cr.openjdk.java.net/~vtewari/8165437/webrev0.6/index.html) The changes mainly look good to me, just a few comments: 1)

Re: RFR (10) : 8177457 and 8177452

> On 19 Apr 2017, at 17:36, Michael McMahon > wrote: > > Could I get the following JDK 10 reviews please. > They are minor doc cleanups, that do not involve spec changes > > https://bugs.openjdk.java.net/browse/JDK-8177457 >

Re: RFR [9] 8177536: Avoid Apple Peer-to-Peer interfaces in networking tests

> On 12 Apr 2017, at 16:17, Roger Riggs wrote: > .. > B6558853.java: 28: an extra "*" > > A few tests do nothing unless an interface is found; they could use either > output that says what > interface is tested or a message that no interface was available. > (In case

RFR [9] 8177536: Avoid Apple Peer-to-Peer interfaces in networking tests

This is a tests only change. Several networking tests appear to fail intermittently on recent Mac machines. In most cases an Apple Peer-to-Peer, awdl0, interface, has been seen to be chosen by the test, for some operation or other, when enumerating the set of network interfaces on the machine.

Re: 9 RFR: 8178147: Race conditions in timeout handling code in http/2 incubator client

> On 7 Apr 2017, at 17:51, Daniel Fuchs wrote: > > Hi Chris, > > Here is the new webrev - where I have incorporated your feedback. > > http://cr.openjdk.java.net/~dfuchs/webrev_8170940/webrev.01/ Looks good to me Daniel. -Chris.

Re: 9 RFR: 8178147: Race conditions in timeout handling code in http/2 incubator client

Daniel, On 06/04/17 11:32, Daniel Fuchs wrote: ... webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8170940/webrev.00/ Looks good Daniel. Just a few comments. 1) Http1Exchange.java Can 'operations' now be made private, and not a synchronizedList? Now that it is operated on only within

Re: RFR [9] 8178161: Default multicast interface on Mac

> On 6 Apr 2017, at 17:50, Michael McMahon wrote: > > Looks fine to me Chris. Stylistically, the boolean tests > in line 104 could remove the == true obviously, but not a big deal. Thanks, I’ll make this change before pushing. -Chris.

RFR [9] 8178161: Default multicast interface on Mac

Because of some peculiarities on Mac the original Mac port brought some code that attempts to determine the default network interface ( on Mac only ). In all cases, on recent OS and hardware, it now finds the Apple peer-to-peer interface, awdl0, which is almost always the wrong answer. This is

Re: Let's improve IPv6 support

On 20/03/17 16:11, Martin Buchholz wrote: On Mon, Mar 20, 2017 at 7:14 AM, Chris Hegarty <chris.hega...@oracle.com <mailto:chris.hega...@oracle.com>> wrote: I should point out that the current batch of changes are focused on support for systems where 127.0.0.1 d

Re: RFR (xs) : 8177144 :sun/net/www/http/HttpClient/B8025710.java should run in ovm mode

Looks good Sean. -Chris. On 20/03/17 16:11, Seán Coffey wrote: Looking for a simple review. Test should be run in ovm mode : https://bugs.openjdk.java.net/browse/JDK-8177144 diff --git a/test/sun/net/www/http/HttpClient/B8025710.java b/test/sun/net/www/http/HttpClient/B8025710.java ---

Re: Let's improve IPv6 support

On 17/03/17 21:12, Paul Marks wrote: On Fri, Mar 17, 2017 at 11:47 AM, Martin Buchholz wrote: Google cares a lot about IPv6, and not only because Vint Cerf works at Google. We have some local modifications and some networking expertise and intend to port/contribute that

Re: Let's improve IPv6 support

Martin, On 17/03/2017 18:47, Martin Buchholz wrote: Google cares a lot about IPv6, and not only because Vint Cerf works at Google. We have some local modifications and some networking expertise and intend to port/contribute that to openjdk10. Most of this is the work of my colleagues

Re: RFR: JDK-8175325 - NetworkInterface.getInterfaceAddresses throws NPE when no addresses

Mark, > On 6 Mar 2017, at 23:21, Mark Sheppard wrote: > > tha's true from the Java side. I didn't exhaustively check if is possible > that the bindings could > be returned uninitialized or null from native code - I don't think it is > possible, but I added the > null

Re: RFR 8175814: HttpClient protocol version needs unspecified value

On 06/03/17 11:00, Daniel Fuchs wrote: On 01/03/17 15:40, Michael McMahon wrote: Hi Could I get the following JDK 9 change reviewed, please? In addition to fixing the spec problem around HTTP version, it fixes an implementation issue with version also, where the per-request version (if set)

RFR [9] 8175261: Per-protocol setting for not working for JAR URLConnection defaultUseCaches

The fix for 8163449 [1] "Allow per protocol setting for URLConnection defaultUseCaches", does not work for JAR URLs ( which embed URLs to the actual artifact ). The problem is that sun.net.www.protocol.jar.JarURLConnection passes all of the [g|s]et[Default]UseCaches() method calls to the

Re: RFR:8170868: DefaultProxySelector should use system defaults on Windows, MacOS and Gnome

> On 31 Jan 2017, at 19:14, Zeller, Arno wrote: > > Hi Chris, > > thanks for all the improvements. I imported your webrev and prepared another > webrev: > http://cr.openjdk.java.net/~clanger/webrevs/8170868.6/ Much better, thanks Arno. Two more minor suggestions ( patch

Re: RFR:8170868: DefaultProxySelector should use system defaults on Windows, MacOS and Gnome

gt; > > Best regards, > Arno > >> -Original Message- >> From: Chris Hegarty [mailto:chris.hega...@oracle.com] >> Sent: Montag, 30. Januar 2017 17:14 >> To: Zeller, Arno <arno.zel...@sap.com> >> Cc: net-dev@openjdk.java.net >> Subject: R

Re: RFR:8170868: DefaultProxySelector should use system defaults on Windows, MacOS and Gnome

Arno, I found an issue on Windows when proxies are specified per-protocol, i.e. they are returned with their optional scheme set. I believe that the scheme should be checked, at least without this change FTP proxies were being returned for HTTP URL's, on my machine. $ hg -R jdk diff diff -r

Re: RFR:8170868: DefaultProxySelector should use system defaults on Windows, MacOS and Gnome

Arno, On 11/01/17 14:21, Zeller, Arno wrote: Hi Chris, I have addressed your comments in a new webrev. Can you please have a look at this one? http://cr.openjdk.java.net/~clanger/webrevs/8170868.3/ This is looking much better, thank you. Some smaller comments and observations ( I'm still

Re: RFR:8170868: DefaultProxySelector should use system defaults on Windows, MacOS and Gnome

proxies. -Chris. > Best regards, > Arno > >> -Original Message- >> From: net-dev [mailto:net-dev-boun...@openjdk.java.net] On Behalf Of >> Zeller, Arno >> Sent: Mittwoch, 11. Januar 2017 15:21 >> To: Chris Hegarty <chris.hega...@oracle.com> >&

Re: RFR [9] Warning notice for types in Incubator Modules

ecipes are created. Setting it on the phony docs-javadoc > target will not help incremental builds. Updated in place http://cr.openjdk.java.net/~chegar/incubator_taglet/ -Chris. > /Erik > > > On 2017-01-24 15:08, Chris Hegarty wrote: >> As per the guidance in JEP 11 [1

RFR [9] Warning notice for types in Incubator Modules

As per the guidance in JEP 11 [1], the javadoc for types in incubator modules should have a clear and explicit warning notice. To that end, I’ve added a simple inline taglet that can be used to effectively inject a standard notice, and applied it to all public types in the HTTP module ( I’ll

Re: RFR: 8167178 Exported elements referring to inaccessible types in java.naming

Looks good. Thanks Vyom. -Chris. > On 16 Jan 2017, at 09:10, Vyom Tewari wrote: > > Hi All, > > Please review below the small fix for the issue. > > BugId : https://bugs.openjdk.java.net/browse/JDK-8167178 > > The compatibility impact is minimum as no code in JDK is

Re: RFR: 8172253 SetIfModifiedSince.java test fails with http return code 404

On 13/01/17 16:42, Daniel Fuchs wrote: On 13/01/17 16:37, Michael McMahon wrote: Could I get the following test change reviewed please? Macos test failure almost certainly caused by the use of a system proxy. Fix is to explicitly specify that proxy must not be used.

Re: [8u-dev]: Request for Review and Approval: 8075484: SocketInputStream.socketRead0 can hang even with soTimeout set

Hi Christoph, > On 9 Jan 2017, at 05:56, Langer, Christoph wrote: > > Ping: Please review this backport to JDK8. > > From: Langer, Christoph > Sent: Donnerstag, 29. Dezember 2016 10:37 > To: net-dev@openjdk.java.net; jdk8u-...@openjdk.java.net > Subject: [8u-dev]:

Re: RFR[9] JDK-8170641: sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.sh fails with timeout

On 27 Dec 2016, at 06:24, John Jiang wrote: > > Hi, > sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.sh failed with > timeout. > The client side could hang if the server goes to timeout before getting the > client request, and the proxy also could be blocked.

Re: RFR:8170868: DefaultProxySelector should use system defaults on Windows, MacOS and Gnome

Arno, > On 27 Dec 2016, at 11:44, Zeller, Arno wrote: > > Hi Chris, > > Thanks for having a look at my change: > >> 1) It seems awful to have to deal with LinkedList in native code. How >> about returning an array from native, and then converting that into >> whatever

Re: RFR: 8170544: Fix code scan findings in libnet

> On 29 Dec 2016, at 13:20, Langer, Christoph wrote: > > Hi Goetz, > > thanks for reviewing this. > > I have addressed your comments in a new webrev: > http://cr.openjdk.java.net/~clanger/webrevs/8170544.1/ This mainly looks fine. Just a few comments: 1)

Re: RFR:8170868: DefaultProxySelector should use system defaults on Windows, MacOS and Gnome

> On 23 Dec 2016, at 15:06, Thomas Stüfe wrote: > > On Fri, Dec 23, 2016 at 11:25 AM, Volker Simonis > wrote: > On Thu, Dec 22, 2016 at 9:41 PM, Thomas Stüfe

Re: RFR:8170868: DefaultProxySelector should use system defaults on Windows, MacOS and Gnome

Arno, > On 22 Dec 2016, at 16:44, Zeller, Arno wrote: > > Hi Vyom, > > thanks for the comments – now I understand the problem. I reworked all three > platforms to check for exceptions and NULL if needed. > Regarding the JNIReleaseString calls: I seem to be on the save

Re: RFR 8168840: InetAddress.getByName() throws java.net.UnknownHostException no such interface when used with virtual interfaces on Solaris

en it will fail to get the sub interface and UHE will be thrown. to handle this i did the code change. Thanks, Vyom On 12/21/2016 5:04 PM, Chris Hegarty wrote: Hi Vyom, Sorry, I'm missing the connection between Inet6Address and NetworkInterface.getByName, how do these interact? -Chris. On 21/

Re: RFR 8168840: InetAddress.getByName() throws java.net.UnknownHostException no such interface when used with virtual interfaces on Solaris

Hi Vyom, Sorry, I'm missing the connection between Inet6Address and NetworkInterface.getByName, how do these interact? -Chris. On 21/12/16 10:20, Vyom Tewari wrote: incorporated the comments(http://cr.openjdk.java.net/~vtewari/8168840/webrev0.2/index.html

Re: RFR: 8163449: Allow per protocol setting for URLConnection defaultUseCaches

> On 19 Dec 2016, at 16:43, Michael McMahon > wrote: > > Could I get the following API (and impl) change reviewed please? > > The change is to add a getter and setter in j.n.URLConnection > for a per-protocol default setting for the useCaches flag. With this >

Re: RFR (M): 8171077: Use getaddrinfo/getnameinfo in Windows Inet4AddresImpl native code

Hi Christoph, > On 12 Dec 2016, at 10:09, Langer, Christoph wrote: > > Hi again, > > this is the Windows part. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8171077 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8171077.0/ I think this looks ok. For

Re: RFR(S): 8171075: Inet4AddressImpl: Remove duplicate and (no longer used ?) native coding for BSD

el.x.mcma...@oracle.com>; Chris Hegarty <chris.hega...@oracle.com>; OpenJDK Network Dev list Subject: RE: RFR(S): 8171075: Inet4AddressImpl: Remove duplicate and (no longer used ?) native coding for BSD Hi Christioph, I had a look at your change. The code you remove is only used if __GLIBC__ is

Re: RFR 8038079: Re-examine integration of SPNEGO authentication

On 13 Dec 2016, at 12:28, Pavel Rappo wrote: > > Hello, > > Could you please review the following change for [1]? > >http://cr.openjdk.java.net/~prappo/8038079/webrev.00/ Looks good. Maybe just a short comment in the module-info.class? // to support SPNEGO from

Re: RFR: 8170920 SO_RCVBUF and SO_SNDBUF options problem for network channels on MacOS

F and SO_SNDBUF options problem for >> network channels on MacOS >> >> >> >> -Original Message- >> From: Michael McMahon [mailto:michael.x.mcma...@oracle.com] >> Sent: Freitag, 9. Dezember 2016 17:19 >> To: Langer, Christoph <christoph.lan.

Re: RFR (S): 8164057: Fix @since for java.net.Inet[46]Address

On 07/12/16 13:05, Langer, Christoph wrote: Hi Chris, Ok, thanks. Let me know when ccc is processed and it can be pushed. You have a green light to push these changes. -Chris. Best regards Christoph -Original Message- From: Chris Hegarty [mailto:chris.hega...@oracle.com] Sent

Re: RFR: 8171081: Put TimeoutOrderingTest in ProblemList for solaris-all

On 12/12/16 11:14, Daniel Fuchs wrote: Hi, Please find below a trivial fix for: https://bugs.openjdk.java.net/browse/JDK-8171081 8171081: Put TimeoutOrderingTest in ProblemList for solaris-all The test is also marked intermittent. http://cr.openjdk.java.net/~dfuchs/webrev_8171081/webrev.00/

Re: RFR: 8170920 SO_RCVBUF and SO_SNDBUF options problem for network channels on MacOS

On 09/12/16 10:33, Michael McMahon wrote: Could I get the following change reviewed please? http://cr.openjdk.java.net/~michaelm/8170920/webrev.1/ Looks good. You may just want to remove the "from" year from the copyright year range in the test, before pushing. -Chris.

Re: JEP 110 moving implementation to incubator module

On 8 Dec 2016, at 18:12, Michael McMahon wrote: > > Hi, > > Bug id 8170648 was filed to do the move and also to bring other work > done in the sandbox back into jdk9/dev. > > The following are the webrevs for the top level repo and for jdk > for this change. > >

Re: RFR(s): 8170864: java/net/URLClassLoader/closetest/CloseTest.java has undeclared dependensies

Sergei, > On 7 Dec 2016, at 14:55, Sergei Kovalev wrote: > > Hi Team, > > Please review a simple fix for networking test. > > BugID: https://bugs.openjdk.java.net/browse/JDK-8170864 > WebRev: http://cr.openjdk.java.net/~skovalev/8170864/webrev.00/ > > Issue: One of

Re: Ping - Re: RFR 8043838, Test java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java failed intermittently in nightly

> On 7 Dec 2016, at 14:48, Daniel Fuchs wrote: > > Hi Felix, > > Looks good in general, but is > 74 return; > intended, or is that a test bug? It is intended, as that is the code path that will be executed when the test invokes itself. -Chris.

Re: Ping - Re: RFR 8043838, Test java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java failed intermittently in nightly

> On 7 Dec 2016, at 14:29, Felix Yang wrote: >>> ... >>> updated webrev. May I have a reviewer to review this >>> >>> http://cr.openjdk.java.net/~xiaofeya/8043838/webrev.01/ I think this is ok Felix. -Chris.

Re: RFR (S): 8164057: Fix @since for java.net.Inet[46]Address

Hi Christoph, > On 7 Dec 2016, at 08:38, Langer, Christoph wrote: > > Hi, > > please review this small fix. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8164057 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8164057.0/ > > The root cause of the wrong

Re: RFR(M): 8167420: remove redundant code path in unix/native/libnet/Inet4AddressImpl.c

regards Christoph -Original Message- From: Chris Hegarty [mailto:chris.hega...@oracle.com] Sent: Montag, 21. November 2016 15:18 To: Langer, Christoph <christoph.lan...@sap.com>; net-dev@openjdk.java.net Subject: Re: RFR(M): 8167420: remove redundant code path in unix/native/

Re: RFR(M): 8167420: remove redundant code path in unix/native/libnet/Inet4AddressImpl.c

Hi Christoph, On 03/11/16 15:46, Langer, Christoph wrote: Hi again, I have to make one addition to my points: Java_java_net_Inet6AddressImpl_getLocalHostName: - made getaddrinfo/getnameinfo turnaround the default, before it was only used on solaris. But it should be the default

Re: RFR (XS): 8169865: Downport minor fixes in java.net native code from JDK 9 to JDK 8

On 17/11/16 12:12, Langer, Christoph wrote: Hi, please review a downport of a few small fixes to JDK 8 which were done through bugs 8034174, 8034182 and 8048518 to JDK 9 already. Bug: https://bugs.openjdk.java.net/browse/JDK-8169865 Webrev:

Re: Parsing too strict in java.net.URI?

David, On 14/11/16 16:47, David M. Lloyd wrote: The following statement: URI uri = URI.create("local:"); fails with an exception like this: java.lang.IllegalArgumentException: Expected scheme-specific part at index 6: local: at java.net.URI.create(URI.java:852) at

Re: RFR: JDK-8164815 - 3 JCK NetworkInterface tests fail on Raspberry Pi

On 10 Nov 2016, at 16:48, Alan Bateman wrote: > On 10/11/2016 16:39, Mark Sheppard wrote: >> Hi, >> please oblige and review the change >> http://cr.openjdk.java.net/~msheppar/8164815/webrev/src/java.base/share/classes/java/net/NetworkInterface.java.sdiff.html >> >>

Re: httpserver does not close connections when RejectedExecutionException occurs

scribe in JIRA, but if you want to investigate that, then that’s fine. -Chris. > > Yasumasa > > > On 2016/11/10 23:00, Chris Hegarty wrote: >> >>> On 9 Nov 2016, at 12:38, Yasumasa Suenaga <yasue...@gmail.com> wrote: >>> >>> Hi Yuji, >>>

Re: httpserver does not close connections when RejectedExecutionException occurs

; Yasumasa > > > On 2016/11/08 18:53, KUBOTA Yuji wrote: >> Hi Chris, >> >> Thank you for your review and updating this issues on JBS. >> >> I filed an issue: >> https://bugs.openjdk.java.net/browse/JDK-8169358 >> >> I don't assig

Re: httpserver does not close connections when RejectedExecutionException occurs

Hi Yuji, On 05/11/16 18:27, KUBOTA Yuji wrote: Hi all, com.sun.net.httpserver in jdk9 does not catch RejectedExecutionException and it does not close connections. We must catch this exception to close a socket. Please review the following patch and reproduce steps. If you agree with that this

Re: RFR: 8169068: Add a new method: java.net.Authenticator.getDefault()

On 03/11/16 17:54, Daniel Fuchs wrote: Hi Chris, Thanks a lot for the feedback. Here is a new webrev incorporating your comments: http://cr.openjdk.java.net/~dfuchs/webrev_8169068/webrev.01 Thanks Daniel, this looks good. -Chris. -- daniel On 03/11/16 14:40, Chris Hegarty wrote

Re: RFR: 8169068: Add a new method: java.net.Authenticator.getDefault()

Daniel, On 03/11/16 10:20, Daniel Fuchs wrote: Hi, Please find below a patch for: RFR: 8169068: Add a new method: java.net.Authenticator.getDefault() https://bugs.openjdk.java.net/browse/JDK-8169068 > The method implementation itself is trivial. The API documentation is derived from that of

Re: RFR 8156504/9, java/net/URLPermission/nstest/lookup.sh fails intermittently

Thanks for doing this Felix. I have some comments about the style and the use of AccessControlContext. Rather than list them I put an alternative version at the following location, please take a look. http://cr.openjdk.java.net/~chegar/8156504_alt/ Note: specifically it is good practice to

Re: RFR(s): 8169002: [TESTBUG] Several java/net/httpclient have undeclared dependency on java.logging module

On 1 Nov 2016, at 18:40, Roger Riggs wrote: > > Hi, > > Ok, leave the logging in. (There are currently 3 issues marked as > intermittent that refer to httpclient). > > Roger > > p.s. I'm also a fan of using the TEST.properties for test directives that > apply to

Re: RFR(S): 8168771: Remove #ifdef AF_INET6 guards in libnet native coding

On 26 Oct 2016, at 10:33, Langer, Christoph wrote: > > Hi, > > please review the cleanup of “#ifdef AF_INET6” in libnet coding. I have > opened a separate JIRA issue as requested > > This is a mailthread where it was already discussed: >

Re: Ping: RFR (M): 8167481: cleanup of headers and includes for native libnet

-Chris. > Thanks & Best regards > Christoph > >> -Original Message- >> From: Chris Hegarty [mailto:chris.hega...@oracle.com] >> Sent: Dienstag, 18. Oktober 2016 20:56 >> To: Langer, Christoph <christoph.lan...@sap.com>; net-dev@openjdk.java.ne

Temporarily remove java/net/httpclient from jdk_net test group

Hi, There are some intermittent test failures in java/net/httpclient. Since development is ongoing over in the sandbox [1], then it is probably best to exclude these tests from the jdk_net test group, in the JDK 9 mainline, temporarily. diff -r a80fd00b0cd0 test/TEST.groups ---

Re: RFR(XXS): 8168471: Non ANSI C declaration of block local variable in NetworkInterface_winXP.c

On 21/10/16 13:49, Volker Simonis wrote: Hi, can I please get a review for the following trivial fix: http://cr.openjdk.java.net/~simonis/webrevs/2016/8168471/ https://bugs.openjdk.java.net/browse/JDK-8168471 Thanks Volker. Reviewed. -Chris. Change "8168405: Pending exceptions in

Re: RFR 8168405: Pending exceptions in java.base/windows/native

> On 20 Oct 2016, at 13:47, Pavel Rappo wrote: > > Hello, > > Could you please review the following change for [1]? > > http://cr.openjdk.java.net/~prappo/8168405/webrev/ Thank you Pavel, this looks good. -Chris. > This change addresses some code paths in the

Re: JDK 9 RFR of JDK-8146257: sun/net/www/protocol/jar/B4957695.java fails intermittently with java.lang.RuntimeException: some jar_cache files left behind

> On 20 Oct 2016, at 11:45, Amy Lu wrote: > > sun/net/www/protocol/jar/B4957695.java > > This test is to verify that no jar_cache tmpFile left in temp directory when > IOException occurs. > > Test do stream reading and trigger IOException and compare the jar_cache file >

Re: RFR: 8157965 update httpserver logging to use java.lang.System.Logger

> On 19 Oct 2016, at 16:29, Daniel Fuchs wrote: > > Thanks Roger! > > On 19/10/16 16:01, Roger Riggs wrote: >> Hi Daniel, >> >> looks fine. >> >> (The style differences are disconcerting but are consistent within the >> file). > > Yes. I preserved the original style

Re: Ping: RFR (M): 8167481: cleanup of headers and includes for native libnet

Christoph, > On 17 Oct 2016, at 09:40, Langer, Christoph wrote: > … > Hi, > > as I already mentioned, here is another proposal for cleanup in libnet: > https://bugs.openjdk.java.net/browse/JDK-8167481 > http://cr.openjdk.java.net/~clanger/webrevs/8167481.0/ Overall,

<    3   4   5   6   7   8   9   10   11   12   >