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

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

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

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

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: Introduce IOException subclass for ECONNRESET

t-dev-boun...@openjdk.java.net] On Behalf Of Chris Hegarty Sent: Montag, 12. September 2016 17:07 To: Florian Weimer <fwei...@redhat.com>; Norman Maurer <norman.mau...@googlemail.com>; net-dev@openjdk.java.net Subject: Re: Introduce IOException subclass for ECONNRESET On 12/09/16 14:50, Floria

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

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:

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

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

this looks good to me. -Chris. > 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. >>

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

le.com] > Sent: Wednesday, September 28, 2016 1:26 AM > To: Chris Hegarty <chris.hega...@oracle.com>; Mark Sheppard > <mark.shepp...@oracle.com>; net-dev <net-dev@openjdk.java.net>; Kaczmarek, > Eric <eric.kaczma...@intel.com>; Viswanathan, Sandhya > &l

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

[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 original invocation of setRe

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

toph. Thanks, -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

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 <felix.y...@oracle.com> 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

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

ot actually need othervm, but of course 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 <felix.y...@oracle.com> wrote: >>> >>> Hi all, >>> >>>pleas

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

that I touch here > and 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

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

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

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

Christoph, On 22/09/16 21:59, Langer, Christoph wrote: Hi, while looking at utility functions for creating exceptions in libjava/libnet I found a small spot that should be consolidated right away. The function NET_ThrowSocketException does only exist in the windows native implementation and

Re: HTTP client API

On 22/09/16 08:54, Chris Hegarty wrote: On 22 Sep 2016, at 00:14, Michael McMahon <michael.x.mcma...@oracle.com> wrote: Martin The source is available in the JDK 9 sandbox (http-client-branch) at http://hg.openjdk.java.net/jdk9/sandbox/ I think it has been updated to reflect t

Re: RFR - 8159410: InetAddress.isReachable returns true for non existing IP addresses

/webrev.03/ Thanks Rob. This latest version looks good to me. -Chris. -Rob On 22/09/16 06:12, Chris Hegarty wrote: On 22 Sep 2016, at 18:04, Mark Sheppard <mark.shepp...@oracle.com> wrote: it is good that you added the additional error code, "cover all bases", as they

Re: RFR 8085049/9, java/net/MulticastSocket/TimeToLive.java fails intermittently with "Address already in use"

Looks good. Thanks Felix. -Chris. On 23/09/16 10:21, Felix Yang wrote: Hi there, please review a minor test fix to avoid hard-coded port usage, which leads to "Address already in use" issue intermittently. Bug: https://bugs.openjdk.java.net/browse/JDK-8085049 Since it is just a 1

Re: RFR - 8159410: InetAddress.isReachable returns true for non existing IP addresses

> On 22 Sep 2016, at 18:04, Mark Sheppard wrote: > > > it is good that you added the additional error code, "cover all bases", as > they say. > In any case your exception handling will inform if something has been > missed, should it occur. > So at the risk of

Re: HTTP client API

On 22 Sep 2016, at 00:14, Michael McMahon wrote: > > Martin > > The source is available in the JDK 9 sandbox (http-client-branch) at > http://hg.openjdk.java.net/jdk9/sandbox/ > > I think it has been updated to reflect the API as described below. Apologies, it

Re: RFR 8166359/9, java/net/URLPermission/nstest/lookup.sh fails if proxy is set, since fix for JDK-8161016

Felix, On 21/09/16 03:31, Felix Yang wrote: Hi Chris, On 2016/9/20 23:22, Chris Hegarty wrote: Felix, On 20 Sep 2016, at 13:57, Felix Yang <felix.y...@oracle.com> wrote: Hi all, please review the following test fix. It explicitly disables proxy to make sure the test not af

Re: RFR(s): 8166285: Missing dependencies java.httpclient for tests from java/net pachage

> On 19 Sep 2016, at 15:33, Sergei Kovalev wrote: > > Hello team, > > Could you please review below fix for: > > BugID: https://bugs.openjdk.java.net/browse/JDK-8166285 > Webrev: http://cr.openjdk.java.net/~skovalev/8166285/webrev.00/ Reviewed. Thanks Sergei.

Re: RFR - 8165988: Test JarURLConnectionUseCaches.java fails at windows: failed to clean up files after test

On 14 Sep 2016, at 21:37, Rob McKenna wrote: > > Hi folks, > > A resource cleanup issue can cause this test to fail on windows, fix is to > run in othervm: > > http://cr.openjdk.java.net/~robm/8165988/webrev.01/ Looks fine Rob. -Chris.

Re: [9] RFR: 8164591: sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java failed with SSLHandshakeException

On 15 Sep 2016, at 02:55, Xuelei Fan wrote: > > On 9/15/2016 9:45 AM, Artem Smotrakov wrote: >> Well, in this particular case it's not clear that it has the same issue >> with free port (at least to me). The exception occurred on client side, >> so it's not the case where

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

, then it seems appropriate that an overriding setReuseAddress(..) method in MulticastSocket can reflect this. That sounds reasonable. -Chris. regards Mark On 14/09/2016 14:58, Chris Hegarty wrote: One additional remark. Was it appropriate to update the legacy MC constructors to set the new JDK 9

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

One additional remark. Was it appropriate to update the legacy MC constructors to set the new JDK 9 SO_REUSEPORT in the first place? This can be achievable, opt-in from new code, by creating an unbound MS, setting the option, then binding. -Chris. On 14/09/16 14:47, Chris Hegarty wrote: Mark

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

and setter methods, in favor of the more general get/setOption methods, as the latter are more adaptable. If setReuseAddress is to operate on more than SO_REUSEADDR, then its spec should be very clear about this. -Chris. regards Mark On 14/09/2016 13:34, Chris Hegarty wrote: Mark, On 14/09/16 13:23

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

java.se.oracle.com/source/s?defs=SO_REUSEPORT=jdk9-dev>, *true*); } as the overridden setReuseAddress takes care of SO_REUSEPORT Yes, this is what Vyom has proposed, in the webrev. I would like to explore an alternative, so see what it would look like. -Chris. regards Mark

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

Vyom, On 11/09/16 08:01, Vyom Tewari wrote: Hi All, Please review the below code change. Bug: https://bugs.openjdk.java.net/browse/JDK-8153674 Webrev : http://cr.openjdk.java.net/~vtewari/8153674/webrev0.0/index.html

Re: RFR 8075484:SocketInputStream.socketRead0 can hang even with soTimeout set

t;>>> >>>> Thanks, >>>> Vyom >>>> >>>> On 9/8/2016 12:32 PM, Langer, Christoph wrote: >>>> >>>>> Hi Vyom, >>>>> >>>>> ok, thanks. I have one addition to my proposal: I don't think there's a >>

Re: Introduce IOException subclass for ECONNRESET

On 12/09/16 14:50, Florian Weimer wrote: On 08/23/2016 09:40 AM, Norman Maurer wrote: Hi all, I first asked this on nio-dev[0] but was asked to move this over to here: I wonder if it would be possible to add a new IOException sub-class for ECONNRESET. Often you receive these errors if a

Re: RFR: 6947916: JarURLConnection does not handle useCaches correctly

t; >>>>> Apologies, I'm guilty of "just doing what adjacent tests do" here. >>>>> >>>>> That shell script is actually there in the test source already, but >>>>> generating the jar from the test means theres no need to use it

Re: RFR: 6947916: JarURLConnection does not handle useCaches correctly

> On 7 Sep 2016, at 14:17, Rob McKenna wrote: > > Hi folks, > > Looking for a review of this simple enough fix: > > http://cr.openjdk.java.net/~robm/6947916/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-6947916 I think that the source changes are good, but the

Re: RFR (XS): JDK-8165711:java/net/SetFactoryPermission/SetFactoryPermission.java needs to run in ovm mode

Reviewed. -Chris. > On 8 Sep 2016, at 16:08, Sean Coffey wrote: > > Looking for review for this simple edit. Testcase should run in ovm mode. > > https://bugs.openjdk.java.net/browse/JDK-8165711 > > patch : > > diff --git

Re: RFR 8075484:SocketInputStream.socketRead0 can hang even with soTimeout set

ards the end of Java_java_net_SocketInputStream_socketRead0, for example EBADF is handled in two places. -Chris. I need help from some one to build and test latest changes on AIX, may be Christoph can help. Thanks, Vyom On Tuesday 06 September 2016 06:25 PM, Chris Hegarty wrote: Vyom, On 6 Sep 2016, at 10:20, Vyom Tewa

Re: RFR 8075484:SocketInputStream.socketRead0 can hang even with soTimeout set

rns before the timeout? Just an idea. -Chris. > Thanks, > > Vyom > > > On Monday 05 September 2016 08:37 PM, Chris Hegarty wrote: >> On 05/09/16 15:37, Mark Sheppard wrote: >>> >>> if the desire is to avoid making double calls on gettimeofday in the >&

Re: RFR 8075484:SocketInputStream.socketRead0 can hang even with soTimeout set

Just no more than is already there. and adjust the originally specified timeout accordingly, and for the edge case after the non blocking read. After an initial skim, your suggestion seems reasonable. -Chris. regards Mark On 05/09/2016 12:02, Chris Hegarty wrote: Vyom, >>> webrev(http://cr.openj

Re: RFR 8075484:SocketInputStream.socketRead0 can hang even with soTimeout set

Vyom, >>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html There is some concern about the potential performance effect, etc, of gettimeofday, maybe there is a way out of this. The reuse of NET_Timeout is good, but it also calls gettimeofday. It seems that a specific

Re: HTTP client API

Martin, Wenbo, We are considering the feedback, will take it under advisement, and reply in due course. -Chris. > On 26 Aug 2016, at 22:14, Martin Buchholz wrote: > > I don't know much about http, but I believe those who say that it's very hard > to get the API right.

Re: [8u-dev] RFR (XXS) and request for approval: 8165320: Small flaw when integrating 8160174 to JDK8

On 02/09/16 15:02, Langer, Christoph wrote: Hi, can you please review and approve a tiny and straightforward fix for AIX only in JDK8. Bug: https://bugs.openjdk.java.net/browse/JDK-8165320 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8165320.8udev/ This looks fine. Reviewed.

Re: Ping: RFR(S): 8163181: Further improvements for Unix NetworkInterface native implementation

Apologies Christoph, this dropped off my list and I forgot to get back to it. > On 2 Sep 2016, at 08:22, Langer, Christoph wrote: > > Hi (Mark or Chris?), > > as this RFR is outstanding for quite a while and it merely is a minor change > which only cleans up coding,

Re: java.net.http orElse(null) in SSLDelegate and other nits

Thanks for reporting these issues Bernd, > On 27 Aug 2016, at 17:25, Bernd Eckenfels wrote: > > Hello, > > trying to understand the new jdk9 hierachy I noticed that this code: > >

Re: Review request JDK-8165180: Provide a shared secret to access non-public ServerSocket constructor

> On 31 Aug 2016, at 21:48, Mandy Chung wrote: > > This patch introduces JavaNetSocketAccess to allow access to non-public > ServerSocket constructor that is accessed by some other area as a clean up. > > Webrev: >

Re: RFR: 8161016: Strange behavior of URLConnection with proxy

On 12/08/16 20:56, Ramanand Patil wrote: Hi Aleksey, Thank you for your review. In the exception handler block: when last proxy fails, it was using a DIRECT connection, but in the fixed version it was just a re-try once with the last proxy before failing the connection. Considering your

Re: RFR 8163561, add a test for Proxy Authentication in HTTP/2 Client API

; Looks good. Thanks Felix. -Chris. > > Thanks, > Felix > On 2016/8/18 23:43, Chris Hegarty wrote: >> On 18 Aug 2016, at 10:26, Felix Yang <felix.y...@oracle.com> wrote: >>> Hi all, >>> >>>please review a new test, which tries t

Re: RFR 8005068: HttpCookie does not correctly handle negative maxAge values

On 24/08/16 13:18, Svetlana Nikandrova wrote: ... Hello, please review this fix. Javadoc for HttpCookie setMaxAge states that " A negative value means that cookie is not stored persistently" and "max age is unspecified", but hasExpired only checks for "-1" as possible negative value. Also

Re: RFR 8163561, add a test for Proxy Authentication in HTTP/2 Client API

On 18 Aug 2016, at 10:26, Felix Yang wrote: > > Hi all, > >please review a new test, which tries to verify "Proxy-Authenticate" > header can be handled correctly. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8163561 > > Webrev:

Re: RFR 8163586: java.net.http.RawChannel has been made public by mistake

Reviewed. -Chris. > On 10 Aug 2016, at 15:37, Pavel Rappo wrote: > > Hello, > > Could you please review the following change for [1]? > > http://cr.openjdk.java.net/~prappo/8163586/webrev.00/ > > The subject field says it all. I've also re-checked the previous

Re: RFR 8162876: [TEST_BUG] sun/net/www/protocol/http/HttpInputStream.java fails intermittently

On 8 Aug 2016, at 13:55, Svetlana Nikandrova wrote: >> ... >> On 02.08.2016 20:25, Svetlana Nikandrova wrote: >>> Pavel, Chris, >>> >>> thank you for you replays. I believe I addressed all Pavel's comments >>> except the one mentioned by Chris below. I saw tests

Re: RFR 8163149/9, Typo in java.net.http.AuthenticationFilter

> On 5 Aug 2016, at 09:05, Felix Yang wrote: > > Hi there, > > please review a simple patch for java.net.http.AuthenticationFilter. There > is a typo in the code. "Proxy-Authentication" should be replaced with > "Proxy-Authenticate" > > Bug:

Re: JDK 9 RFR of 8162745: content-types.properties files are missing some modern types

> On 3 Aug 2016, at 14:32, Brian Burkhalter wrote: > > Please review at your convenience. > > Issue:https://bugs.openjdk.java.net/browse/JDK-8162745 > Patch:http://cr.openjdk.java.net/~bpb/8162745/webrev.00/ >

Re: RFR 8162876: [TEST_BUG] sun/net/www/protocol/http/HttpInputStream.java fails intermittently

> On 1 Aug 2016, at 12:03, Pavel Rappo wrote: > ...return len; > > 5. I believe we should add 8162876 to @bug Strictly speaking, we should not. The @bug should capture the bug numbers that the test exercises the changes for. It is not necessary to include the bug

Re: RFR 8161291: Serialization Tests for URLPermission is failing

On 22/07/16 09:59, Daniel Fuchs wrote: Hi Vyom, It would be helpful in the future to include a link to the JBS issue in your request for review. 464 //The colon separator need to be present even if the request headers list is empty I would suggest the comment to be a little more

Re: PING: RFR (S) JDK-8160174: java.net.NetworkInterface - fixes and improvements for network interface listing

in advance Christoph -Original Message- From: Langer, Christoph Sent: Mittwoch, 13. Juli 2016 17:02 To: 'Chris Hegarty' <chris.hega...@oracle.com> Cc: net-dev@openjdk.java.net Subject: RE: RFR (S) JDK-8160174: java.net.NetworkInterface - fixes and improvements for network interface listi

Re: RFR [9] 8078568 java/net/URLPermission/URLTest.java fails intermittently with BindException

ww.protocol.http.HttpURLConnection.getInputStream0(java.base/HttpURLConnection.java:1505) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(java.base/HttpURLConnection.java:1433) at java.net.HttpURLConnection.getResponseCode(java.base/HttpURLConnection.java:480) ... 10 more cheers, -- danie

RFR [9] 8160993: Fix headers in the java/net/http package

This is a change fix the license headers in the java/net/http package. There was a cut'n'paste error that mostly missed the last line of the header. Also, I added a new line after the header consistently in every file. As well as a few places that had other minor issues.

Re: RFR JDK-8161091 Incorrect Stream.FlowControl implementation allows to send DataFrame even when window size was exhausted

> On 11 Jul 2016, at 23:47, Sergey Kuksenko wrote: > > I am awfully sorry, previous fix was incorrect. > Please, review the right version: > http://cr.openjdk.java.net/~skuksenko/jep110/8161091/webrev.01/ Looks good. Thanks Sergey. -Chris. > On 07/08/2016 02:40

Re: Help needed: Java Socket and close detection

Some further reading… https://docs.oracle.com/javase/8/docs/technotes/guides/net/articles/connection_release.html -Chris. > On 13 Jul 2016, at 21:37, Dmitry Samersoff > wrote: > > Christoph, > > My $0.2 > > Typically you see RST packet when the data come to a

Re: RFR 8022580: sun.net.ftp.impl.FtpClient.nameList(String path) handle "null" incorrectly

.04/> Hi Svetlana, The test looks good to me know :-) best regards, -- daniel Thank you, Svetlana On 12.07.2016 17:25, Chris Hegarty wrote: Svetlana, <http://cr.openjdk.java.net/%7Esnikandrova/8022580/webrev.03/> The source code changes look fine. On the test... On 11 Jul 20

Re: RFR 8144692: HttpServer API: use of non-existant method in example in package Javadoc

On 12/07/16 13:53, Vyom Tewari wrote: Hi Pavel, Thanks for review, i updated the webrev(http://cr.openjdk.java.net/~vtewari/8144692/webrev0.0/index.html ) in place. Looks fine. -Chris. Thanks, Vyom On Tuesday 12 July

Re: RFR (S) JDK-8160174: java.net.NetworkInterface - fixes and improvements for network interface listing

Christoph, > On 11 Jul 2016, at 14:36, Langer, Christoph wrote: > > Hi Chris (or anyone who is holding a stake in the NetworkInterface native > implementation), > > I’ve spent some time on cleaning up NetworkInterface.c and came up with a > bigger

Re: RFR: 8160786: No CCC for public class java.net.http.AsyncSSlDelegate

On 11/07/16 13:42, Michael McMahon wrote: Simple change. An implementation class was made public by mistake http://cr.openjdk.java.net/~michaelm/8160786/webrev.1/ Reviewed. -Chris.

Re: Preliminary RFR JDK-8159053: Improve onPing/onClose behavior

On 23/06/16 18:09, Simone Bordet wrote: Hi, On Thu, Jun 23, 2016 at 7:00 PM, Pavel Rappo wrote: But I still think we probably more safe assuming the intersection of our understandings, rather than a union :-) Chris and I agreed, so now you're minority :) Well, I

Re: RFR JDK-8158690 "GET request via HTTP/2 has a huge delays due to Nagle’s Algorithm and Delayed ACK clash"

Pushed: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1f3481f377e6 -Chris. > On 23 Jun 2016, at 10:41, Chris Hegarty <chris.hega...@oracle.com> wrote: > > Sergey and I discuss this off-line and the potential performance improvement > here is very significant; raises performan

Re: Preliminary RFR JDK-8159053: Improve onPing/onClose behavior

> On 23 Jun 2016, at 15:36, Simone Bordet <simone.bor...@gmail.com> wrote: > > Hi, > > On Thu, Jun 23, 2016 at 3:58 PM, Chris Hegarty <chris.hega...@oracle.com> > wrote: >> At one point I thought the same, but after, yet another, re-reading of the

Re: Preliminary RFR JDK-8159053: Improve onPing/onClose behavior

> On 23 Jun 2016, at 14:48, Simone Bordet wrote: > > ... > > WebSocket's close mechanism is a double half close, like TCP. > In TCP the semantic is very clear: sideA can half close, sideB can > continue sending data, sideA will continue reading data, until sideB > half

Re: RFR JDK-8158690 "GET request via HTTP/2 has a huge delays due to Nagle’s Algorithm and Delayed ACK clash"

, if necessary. And/Or make implementation changes if issues arise from this. -Chris. > On 21 Jun 2016, at 06:56, Chris Hegarty <chris.hega...@oracle.com> wrote: > > On 20 Jun 2016, at 21:36, Sergey Kuksenko <sergey.kukse...@oracle.com> wrote: >> >> Hi, >> &

Re: RFR 8071660 :URLPermission not handling empty method lists correctly

On 21 Jun 2016, at 11:21, Chris Hegarty <chris.hega...@oracle.com> wrote: > > The code changes look fine, but the bigger question is whether we > want to support actions without any ‘method’ being specified, like > “:X-Bar”? Should the constructor throw IAE, or is that e

Re: RFR JDK-8156742: Miscellaneous WebSocket API improvements

> On 21 Jun 2016, at 12:21, Pavel Rappo wrote: > > Hi, > > Let me try again to propose the following set of changes: > > http://cr.openjdk.java.net/~prappo/8156742/webrev.02/ This mainly looks fine, just a small comment: - WebSocket.java "Or to close abruptly

Re: RFR 8071660 :URLPermission not handling empty method lists correctly

The code changes look fine, but the bigger question is whether we want to support actions without any ‘method’ being specified, like “:X-Bar”? Should the constructor throw IAE, or is that even possible now, it would require a spec clarification ( would that invalidate existing code already doing

Re: Preliminary RFR JDK-8159053: Improve onPing/onClose behavior

I think this is good. Just some ideas to simplify the wording. * After a Close message has been received, the implementation will * close the connection automatically. However, the client may finish * sending the current sequence of partially sent message parts, if any. * To

Re: RFR 8144008: Setting NO_PROXY on an URLConnection is not complied with

(); +return new java.net.Socket(Proxy.NO_PROXY)); } protected InetAddress getLocalAddress() throws IOException { if (serverSocket == null) throw new IOException("not connected”); -Chris. > On 16 Jun 2016, at 21:09, Chris Hegarty <chris.hega...

Re: Preliminary RFR JDK-8159053: Improve onPing/onClose behavior

I think this is good Pavel, just a few minor comments. > On 17 Jun 2016, at 19:37, Pavel Rappo wrote: > > …. > * The WebSocket implementation responds to the received Ping > * message using a strategy of its choice, but withing the boundaries of

Re: Preliminary RFR JDK-8159053: Improve onPing/onClose behavior

I think this is good Pavel, just a few minor comments. > On 17 Jun 2016, at 19:37, Pavel Rappo wrote: > > …. > * The WebSocket implementation responds to the received Ping > * message using a strategy of its choice, but withing the boundaries of

Re: RFR JDK-8158980: Memory leak in HTTP2Connection.streams

> On 20 Jun 2016, at 21:24, Sergey Kuksenko wrote: > > Hi, > > Could you please review the following fix for JDK-8158980? > http://cr.openjdk.java.net/~skuksenko/jep110/8158980/webrev.00/ This looks good to me Sergey. I can sponsor it for you. -Chris.

Re: RFR 8071660 :URLPermission not handling empty method lists correctly

On 17/06/16 15:09, Vyom Tewari wrote: Hi, Please find the latest webrev(http://cr.openjdk.java.net/~vtewari/8071660/webrev0.3/index.html ). I fixed the typo along with spaces issue. Thanks Vyom. Looks good. -Chris.

Re: RFR: 8159745: Remove java.net.Parts

On 17/06/16 15:05, Claes Redestad wrote: On 2016-06-17 16:04, Alan Bateman wrote: On 17/06/2016 14:43, Claes Redestad wrote: Hi, URL.java defines a package-private class Parts, which can be trivially inlined in the one place where it's currently used. Webrev:

Re: RFR 8144008: Setting NO_PROXY on an URLConnection is not complied with

> On 16 Jun 2016, at 18:55, Roger Riggs wrote: > > Hi Vyom, > > Looks ok, +1. I attempted to add a test for https, and just realised that the javax.net.SocketFactory does not support Socket(Proxy). It may be worth capturing this issue somewhere, but it is way

Re: RFR [9] 8157166: Update spec to account for platforms that do not support multicast

> On 16 Jun 2016, at 16:31, Alan Bateman <alan.bate...@oracle.com> wrote: > > On 16/06/2016 16:03, Chris Hegarty wrote: > >> Some platforms do not support multicasting, but the current spec requires >> that >> it is supported. It seems re

RFR [9] 8157166: Update spec to account for platforms that do not support multicast

Some platforms do not support multicasting, but the current spec requires that it is supported. It seems reasonable to relax this, somewhat, so that multicasting is effectively optional on these platforms. java.net.MulticastSocket.joinGroup and java.nio.channels.MulticastChannel.join method

Re: RFR JDK-8157273: Simplify outgoing messages queueing policy in WebSocket API

> On 14 Jun 2016, at 17:24, Simone Bordet wrote: > >> ... > > However, you still want to use the CFs for exception reporting. Of course. We should not introduce a model that is at odds with how exceptions are handled in this API. How about: 1) Leave the sendXXX

RFR [9] 8157045: NPE during websocket communication with wss

8157045 [1] is blocking folks doing test development for WebSockets. I would like to push this “temporary” change, to unblock them, until we can refactor some of this area to fix what appears to be a more significant issue ( readImpl(ByteBuffer) can read bytes into a different ByteBuffer, but

Re: RFR JDK-8157273: Simplify outgoing messages queueing policy in WebSocket API

Following this discussion, I think the point is that the size of the send queue is an implementation detail, and therefore cannot be replied upon ( another implementation could have a smaller upper bound ). Having a method on builder similar to the sketch below, may address this concern. /**

Re: RFR JDK-8159039: sun/net/httpclient/hpack/HeaderTableTest.java fails on some locales

On 13/06/16 16:39, Naoto Sato wrote: Hi Pavel, Locale.setDefault() sets the JVM wide default locale, so I'd suggest add try/finally block to resume the locale to the previous one. I did suggest something like this to Pavel off-list, but then noticed that the test runs in othervm mode, so

Re: RFR JDK-8159039: sun/net/httpclient/hpack/HeaderTableTest.java fails on some locales

Thanks Pavel. Reviewed. -Chris. On 13/06/16 11:29, Pavel Rappo wrote: Hi, Could you please review the following change for JDK-8159039? http://cr.openjdk.java.net/~prappo/8159039/webrev.00/ This change contains a fix for 8159039 as well as a number of tiny editorial changes. Thanks, -Pavel

Re: 8158519: Incorrect network mask and broadcast address on Linux when there are multiple IPv4 addresses on an interface

s change got pushed. > > Thanks and Best regards > Christoph > > >> -Original Message- >> From: net-dev [mailto:net-dev-boun...@openjdk.java.net] On Behalf Of Dmitry >> Samersoff >> Sent: Donnerstag, 2. Juni 2016 19:35 >> To: Chris Hegarty <chris.

Re: RFR JDK-8157273: Simplify outgoing messages queueing policy in WebSocket API

Looks fine. -Chris. On 09/06/16 11:54, Pavel Rappo wrote: Hi, Could you please review the following change for JDK-8157273? http://cr.openjdk.java.net/~prappo/8157273/webrev.01/ This change addresses some WebSocket API refinements and enhancements from [1]. Currently WebSocket API allows

RFR [9] 8041924: [TESTBUG] sun/net/www/http/ChunkedOutputStream/checkError.java fails on some systems

This test has been seen to fail intermittently. There is an assumption in the test that the client-side will fill the outgoing TCP buffer by writing 1 megabyte of data, allowing for the server-side to close the connection out from under it. This is the crux of the test. By slowing down the

Re: JDK 9 RFR of JDK-8159012: Problem list sun/net/www/http/ChunkedOutputStream/checkError.java

Looks fine Amy. -Chris. > On 8 Jun 2016, at 01:48, Amy Lu wrote: > > sun/net/www/http/ChunkedOutputStream/checkError.java > This test failed intermittently (JDK-8041924), and recently observed failing > with high frequency. > > Please review this patch to put the test to

Re: RFR of JDK-8158881: Doc typo in src/../java/net/URI.java

e changed URLs in doc are not valid URLs, they just sample. > Please check webrev: http://cr.openjdk.java.net/~mli/8158881/webrev.01/ Thank you Hamlin ( and Brad ), this looks good. -Chris. > Thank you > -Hamlin >> >> Thanks, >> >> Brad >> >> [1

Re: RFR of JDK-8158881: Doc typo in src/../java/net/URI.java

> On 7 Jun 2016, at 05:50, Hamlin Li wrote: > > Would you please review the following simple doc patch? > > bug: https://bugs.openjdk.java.net/browse/JDK-8158881 > webrev: http://cr.openjdk.java.net/~mli/8158881/webrev.00/ I’m not sure why the URL’s were ever changed

Re: RFR [9] 8158525: Update a few java/net tests to use the loopback address instead of the host address

). It works fine all systems I’ve tested with. Update in-palce: http://cr.openjdk.java.net/~chegar/8158525/ -Chris. > Roger > > > > On 6/2/2016 9:22 AM, Chris Hegarty wrote: >> The following networking tests have been seen to fail from a timeout, when >> the host

8158519: Incorrect network mask and broadcast address on Linux when there are multiple IPv4 addresses on an interface

Doychin, et al, I finally got time to look at the issue you reported and your suggested patch. I filed 8158519 [1] to track the issue. I think your suggested patch may be ok, but I just wanted to push on the ioctl approach. I found an alternative, and verified that it works as expected.

Re: Ping - RFR 8158023: SocketExceptions contain too little information sometimes

Christoph, > On 1 Jun 2016, at 08:33, e...@zusammenkunft.net wrote: > > Hello, > > Since nobody commented, here is my non binding comment: > > I am not sure which Exception call-site actually improved (i.e. added the > error code)? I would split out the improvement of this/those throws and

Re: Reminder about reported problem in NetworkInterface.c

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

Re: RFR 8157816, Mark 4 httpclient tests as intermittently failing

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

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