Re: RFR 8154525, java/net/ServerSocket/ThreadStop.java fails intermittently with error while cleaning up threads after test

> On 27 Sep 2016, at 03:08, Felix Yang wrote: > > Hi all, > >please review following test fix. > > Bug: > >https://bugs.openjdk.java.net/browse/JDK-8154525 > > Webrev: > >http://cr.openjdk.java.net/~xiaofeya/8154525/webrev.00/ > > This test has been observed to fail sometimes w

Re: RFR - 8166747: Add invalid network / computer name cases to isReachable known failure switch

On 27 Sep 2016, at 01:02, Mark Sheppard wrote: > > Hi Rob, >changes look reasonable … +1 > perhaps align the two additions below the existing ERROR_XXX set, all neat > and tidy :-) +1 -Chris. > regards > Mark > > On 27/09/2016 00:09, Rob McKenna wrote: >> Hi folks, >> >> Looking for a

Re: RFR(XS): 8166584: Remove obsolete utility function NET_ThrowSocketException in windows libnet

if yes, shall I use the literal name or the JNU_JAVANETPKG define? Any > opinion on that? My preference is to remove JNU_JAVANETPKG, and just use "java/net/“. -Chris > Thanks for taking care of this, > Christoph > > >> -Original Message- >> From: Chris H

Re: RFR 8154525, java/net/ServerSocket/ThreadStop.java fails intermittently with error while cleaning up threads after test

it should be fine with it too. -Chris. > Thanks, > Felix > On 2016/9/27 15:55, Chris Hegarty wrote: >>> On 27 Sep 2016, at 03:08, Felix Yang wrote: >>> >>> Hi all, >>> >>>please review following test fix. >>> >

Re: RFR 8154525, java/net/ServerSocket/ThreadStop.java fails intermittently with error while cleaning up threads after test

On 27 Sep 2016, at 09:35, Felix Yang wrote: > > Chris, > >I will push without othervm Thanks. If we see future issues with this test, then we can add it back. -Chris. > -Felix > On 2016/9/27 16:29, Chris Hegarty wrote: >> On 27 Sep 2016, at 09:25, Felix Y

Re: RFR(XS): 8166584: Remove obsolete utility function NET_ThrowSocketException in windows libnet

anks, -Chris. > I've replaced the JNU_JAVANETPKG and JNU_JAVAIOPKG macros with the full > exception class names. > > Best regards > Christoph > >> -Original Message- >> From: Chris Hegarty [mailto:chris.hega...@oracle.com] >> Sent: Dienstag, 27. September 2016

Re: RFR 8153674: Expected SocketException not thrown when calling bind() with setReuseAddress(false)

-Chris. [1] https://bugs.openjdk.java.net/browse/JDK-6432031 Thanks, Vyom On Wednesday 14 September 2016 08:47 PM, Chris Hegarty wrote: On 14/09/16 15:53, Mark Sheppard wrote: that's true wrt SO_REUSEPORT in MulticastSocket constructor. But the same could have been argued for the

Re: RFR 8153674: Expected SocketException not thrown when calling bind() with setReuseAddress(false)

_REUSEPORT behave the same way for > MulticastSocket. There is no need to check and enable SO_REUSEPORT for this > particular type of socket. SO_REUSEADDR is sufficient. > > Thanks, > Lucy > > <>From: Vyom Tewari [mailto:vyom.tew...@oracle.com] > Sent: Wednes

Re: RFR 8153674: Expected SocketException not thrown when calling bind() with setReuseAddress(false)

ris. > Thanks, > > Vyom > > On Thursday 29 September 2016 01:38 AM, Chris Hegarty wrote: >> Thank you Lucy, >> >> We’ll proceed with removing the setting of SO_REUSEPORT from the >> MulticastSocket constructor and spec. >> >> -Chris. >>

Re: RFR(S): 8166850: No runtime error expected after calling NET_MapSocketOption

On 28 Sep 2016, at 16:39, Langer, Christoph wrote: > > Hi, > > during my work on exception sites in the JDK, I spotted another minor place > that should be fixed. In the Windows native implementations of > DualStackPlainDatagramSocketImpl and DualStackPlainSocketImpl, there are > calls to ev

Re: RFR(s): 8166791: Fix module dependencies for networking component tests

Sergei, On 03/10/16 11:08, Sergei Kovalev wrote: Resending this for review 27.09.16 18:44, Sergei Kovalev wrote: Hi team, Could you please review small fix for regression tests. BugID: https://bugs.openjdk.java.net/browse/JDK-8166791 WebRev: http://cr.openjdk.java.net/~skovalev/8166791/webr

Re: RFR(s): 8166791: Fix module dependencies for networking component tests

On 03/10/16 14:43, Sergei Kovalev wrote: Fixed http://cr.openjdk.java.net/~skovalev/8166791/webrev.02/ java.compiler already exports javax.tools so no need for the explicit export in the @modules tag. Otherwise this is fine. -Chris. 03.10.16 16:36, Alan Bateman wrote: On 03/10/2016 14:3

Re: RFR(s): 8166791: Fix module dependencies for networking component tests

On 03/10/16 15:19, Sergei Kovalev wrote: Changed http://cr.openjdk.java.net/~skovalev/8166791/webrev.03/ This looks fine. Reviewed. No need to generate the webrev, but can you please check that you list the java.* modules before the jdk.* ones. Thanks, -Chris. 03.10.16 17:07, Alan Bateman

Re: Introduce IOException subclass for ECONNRESET

[mailto:net-dev-boun...@openjdk.java.net] On Behalf Of Chris Hegarty Sent: Montag, 12. September 2016 17:07 To: Florian Weimer ; Norman Maurer ; net-dev@openjdk.java.net Subject: Re: Introduce IOException subclass for ECONNRESET On 12/09/16 14:50, Florian Weimer wrote: On 08/23/2016 09:40 AM, Norman Maure

Re: RFR 8163482: java.net.URLPermission.getActions() adds a trailing colon when header-names is empty

> On 6 Oct 2016, at 08:31, Vyom Tewari wrote: > > Hi All, > > Please find the spec change for below issue. > > BugId : https://bugs.openjdk.java.net/browse/JDK-8163482 > > Webrev : http://cr.openjdk.java.net/~vtewari/8163482/webrev0.0/index.html >

Re: RFR(L): 8167295: Further cleanup to the native parts of libnet/libnio

Hi Christoph, On 07/10/16 16:17, Langer, Christoph wrote: Hi again, I have respun my patch a little bit: http://cr.openjdk.java.net/~clanger/webrevs/8167295.1/ This is a nice cleanup and an improvement to the code. Specifically, adding 'struct sockaddr sa' to SOCKETADDRESS allows for the remo

Re: AF_INET6 support

Christoph, > On 13 Oct 2016, at 07:19, Langer, Christoph wrote: > > Hi networking experts, > > I’ve got a question regarding AF_INET6. > > In jdk native code you’ll still find lots of code guarded by “#ifdef > AF_INET6”. I’m wondering if there are still supported build environments > wher

Re: Ugly things done to support multiple ContentHandlerFactory and URLStreamHandlerFactory

Hi Tom, We are aware of some of these issues, but I have to admit that I still don't have a good handle on all the use-cases. One of the more straight forward is the "wrapping" of the built-in handlers, for the case where the framework does not want to re-implement all the existing JDK supported

Re: [8u-dev] Request for Review + Approval: Backport of 8163181: Further improvements for Unix NetworkInterface native implementation

> On 17 Oct 2016, at 09:38, Langer, Christoph wrote: > > Hi, > > please review (@Chris or Mark) and approve the following downpour. From my point of view, I’m ok with this. You still need 8u maintainer approval. > Bug: https://bugs.openjdk.java.net/browse/JDK-8163181 > Original Change: http

Re: AF_INET6 support

On 13 Oct 2016, at 09:46, Langer, Christoph wrote: > > Hi Chris, > >>> I’ve got a question regarding AF_INET6. >>> >>> In jdk native code you’ll still find lots of code guarded by “#ifdef >>> AF_INET6”. >> I’m wondering if there are still supported build environments where AF_INET6 >> is not

Re: [9] RFR: 8166530: sun/net/www/protocol/https/HttpsClient/ProxyAuthTest.java fails intermittently

> On 7 Oct 2016, at 21:33, Artem Smotrakov wrote: > > Hello, > > Please review the patch below for > sun/net/www/protocol/https/HttpsClient/ProxyAuthTest.java test. > > The test has been observed to fail intermittently, but the failure is not > reproducible standalone. The patch updates the

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, this looks good. Specific c

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 though it was hurting > m

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 > number before and af

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 native networking code for >

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 java.base

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 --- a/test/TEST.grou

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

egards > Christoph > >> -Original Message- >> From: Chris Hegarty [mailto:chris.hega...@oracle.com] >> Sent: Dienstag, 18. Oktober 2016 20:56 >> To: Langer, Christoph ; net-dev@openjdk.java.net >> Subject: Re: Ping: RFR (M): 8167481: cleanup of headers and

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: > http://mail.openjdk.java.net/pipermail/net-dev/2016-O

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 multiple tests > in a direc

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 r

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: 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(s): 8169316: com/sun/net/httpserver tests have undeclared dependency on java.logging

On 07/11/16 11:42, Sergei Kovalev wrote: Hi Team, Please review a very small fix for test suite. BugID: https://bugs.openjdk.java.net/browse/JDK-8169316 WebRev: http://cr.openjdk.java.net/~skovalev/8169316/webrev.00/ I think this is fine Sergei. Thanks, -Chris. Issue: bunch of tests have

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: httpserver does not close connections when RejectedExecutionException occurs

t; > 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 assign to me because I'm no

Re: httpserver does not close connections when RejectedExecutionException occurs

estigate 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 wrote: >>> >>> Hi Yuji, >>> >>>> http://cr.openjdk.java.net/~ykubota/816

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 >> >> >> to address the issue ra

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 org.jboss.ejb.client

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: http://cr.openjdk.java.net/~clanger/webrevs/8169865.8

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 since

Re: HTTP client API

Tobias, If you look at the code in the sandbox [*], the notion of a default client has been removed. Having global static default instances is problematic. Http Clients are lightweight, easy to configure and pass around, if that is what you want. -Chris. [*] hg clone http://hg.openjdk.java.net/

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

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

Re: RFR: 8169495: Add a method to set an Authenticator on a HttpURLConnection.

On 10/11/16 15:12, Daniel Fuchs wrote: Hi, Please find below a patch for: https://bugs.openjdk.java.net/browse/JDK-8169495 8169495: Add a method to set an Authenticator on a HttpURLConnection. Thank you Daniel. This addresses a long standing request to have a per-instance Authenticator. web

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 “@since” tags probably is t

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: 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. > best regards, > > -- d

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 networking tests fails in c

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. > > http://cr.openjdk.java.net/~mic

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: 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 (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: 8170920 SO_RCVBUF and SO_SNDBUF options problem for network channels on MacOS

> 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 >> Cc: Chris Hegarty ; OpenJDK Network Dev list >> >>

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 HttpURLConnection -Chri

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

lways be in ordered as per getaddrinfo ( not sure why the order was ever reversed ). -Chris. Best regards Christoph -Original Message- From: Lindenmaier, Goetz Sent: Freitag, 16. Dezember 2016 11:11 To: Langer, Christoph ; 'Michael McMahon' ; Chris Hegarty ; OpenJDK Network De

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 consistency, should the code ‘

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 > change it will be possible to swi

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 8168840: InetAddress.getByName() throws java.net.UnknownHostException no such interface when used with virtual interfaces on Solaris

:0:0:0:17%net0:1) then 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 i

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 sidether. They > are l

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 > wrote: > > ... > > 1) The naming of the unix...DefaultProxySelector.c

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) NetworkInterface.c I’m not sure

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 list type is appropri

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. > > This patch sets t

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]: Request for Review and Appro

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

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 currently depend on > i

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 cleanu

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

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], the javadoc for types in &g

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

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 >> Cc: net-dev@openjdk.java.net >>

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 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 07e0

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

ds, > Arno > >> -Original Message- >> From: Chris Hegarty [mailto:chris.hega...@oracle.com] >> Sent: Montag, 30. Januar 2017 17:14 >> To: Zeller, Arno >> Cc: net-dev@openjdk.java.net >> Subject: Re: RFR:8170868: DefaultProxySelector should use syste

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 below ): 1) As sugge

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 embedded

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) was

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 check, just in case. I ag

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 Alexand

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 to openjdk10. Most of

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 --- a/test

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 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 doesn't exist, which is

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 frag

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.

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: 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

> On 11 Apr 2017, at 12:51, Daniel Fuchs wrote: > > Hi, > > Please find below a new webrev that fixes an additional timeout > ordering issue I discovered while testing: > > http://cr.openjdk.java.net/~dfuchs/webrev_8170940/webrev.02/ Thanks for going the extra mile on this one. Good catch, an

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. Suc

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 someone is reviewing the lo

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 > https://bugs.openjdk.java.net/browse/JDK-8177452 > > 8177457 Syntax

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) src/java.base/unix/native/libnet/PlainSocketImpl.c

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] http://cr.openjdk.java.net/~akasko/jdk8u/8035653/webre

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 > https://bugs.openjdk.java.net/browse/JDK-8179273 > > webrev: > http://

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) src/java.base/unix/native/libnet/PlainSocket

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: RFR [9] 8179392: Fix warnings in the httpclient javadoc

> On 27 Apr 2017, at 11:56, Daniel Fuchs 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 > > On 27/04/2017 11:53,

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: >> http://cr.openjdk.java.net/~michaelm/81758

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 performing the initial handshake. The u

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. AsyncConne

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 bash

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 original > change, and go back to the

<    1   2   3   4   5   6   7   8   9   10   >