Re: RFR 8136933: Additional tests for Solaris SO_FLOW_SLA socket option in JDK 9

On 25 May 2016, at 14:04, Svetlana Nikandrova wrote: > > Hi Chris, > > thank you for your comments. Please see updated review. (I left braces in one > line "if" blocks, hope it wasn't strong objection) > > http://cr.openjdk.java.net/~snikandrova/8136933/webrev.04/ >

Re: RFR 8157811 [9] Additional minor fixes and cleanups in Networking native code

.lifr_flags; > > Best regards > Christoph > >> -Original Message- >> From: net-dev [mailto:net-dev-boun...@openjdk.java.net] On Behalf Of Chris >> Hegarty >> Sent: Mittwoch, 25. Mai 2016 11:50 >> To: OpenJDK Network Dev list >> Subject: RFR 8

Re: Reminder about reported problem in NetworkInterface.c

> On 26 May 2016, at 13:46, Doychin Bondzhev wrote: > > Hi, I have my signed Oca processed. I hope now we can continue with proposed > patch? I cannot find you on http://www.oracle.com/technetwork/community/oca-486395.html#list Please confirm your that you are on this list. Chris.

Re: Reminder about reported problem in NetworkInterface.c

> On 26 May 2016, at 13:57, Chris Hegarty wrote: > > >> On 26 May 2016, at 13:46, Doychin Bondzhev wrote: >> >> Hi, I have my signed Oca processed. I hope now we can continue with >> proposed patch? > > I cannot find you on > http://www.oracle

RFR [9] 8085785: sun/net/www/protocol/http/ZoneId.java timeout intermittently

ZoneId is attempting to verify the 'Host' header set by the HttpURLConnection implementation when given an IPv6 literal containing a scope id. It does so by iterating the network interfaces on the machine attempting to find one that is suitable to use as the listening interface for a temporar

Re: Reminder about reported problem in NetworkInterface.c

the NetworkInterface.c code at that time. > > If it is needed I can update it against current code. Yes, please. And can you please post the patch to this mailing list. I’m loath to go off openjdk infrastructure. -Chris. > Have a nice day, > Doychin Bondzhev > > On Thu,

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 test/java/net

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 http://downloa

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 the

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

Re: Reminder about reported problem in NetworkInterface.c

For the record, this issue is tracked by 8158519 [1], and discussion will continue on another thread: http://mail.openjdk.java.net/pipermail/net-dev/2016-June/009885.html -Chris. [1] https://bugs.openjdk.java.net/browse/JDK-8158519 > On 30 May 2016, at 13:51, Doychin Bondzhev wrote: > > At

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

The following networking tests have been seen to fail from a timeout, when the host is not accessible. These tests have nothing whatsoever to do with testing of network connections, they simply want to test the HTTP client implementation. This issue proposes to change the tests from using the

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

ems 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 >> is not accessib

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 from java.sun.com, since t

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

oc 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] RFC 2606: https://tools.i

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 problem list until J

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 writes

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 on

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

gt; > 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 ; Doychin Bondzhev >> ; OpenJDK N

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: 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 won't

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. /**

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 has

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 methods as they are, no change

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 spec

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

> On 16 Jun 2016, at 16:31, Alan Bateman 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 reasonable to relax this, somewhat, so that >

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 beyond the scope of this bug,

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

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

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: 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-8158690 "GET request via HTTP/2 has a huge delays due to Nagle’s Algorithm and Delayed ACK clash"

On 20 Jun 2016, at 21:36, Sergey Kuksenko wrote: > > Hi, > > Could you please review the following fix for JDK-8158690? > > http://cr.openjdk.java.net/~skuksenko/jep110/8158690/webrev.00/ > > Fix solves the following issue: > https://bugs.openjdk.java.net/browse/JDK-8158690 Hmmm….. I’m not

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

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 faci

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: 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 call {@link #abort()}.” Rat

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

On 21 Jun 2016, at 11:21, Chris Hegarty 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 even possible > now, it would

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

Pushed: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/bae5b550b829 -Chris. > On 22 Jun 2016, at 22:17, Sergey Kuksenko wrote: > > Please, do this. > > On 06/20/2016 10:17 PM, Chris Hegarty wrote: >>> On 20 Jun 2016, at 21:24, Sergey Kuksenko >>> wrote: >&

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

necessary. And/Or make implementation changes if issues arise from this. -Chris. > On 21 Jun 2016, at 06:56, Chris Hegarty wrote: > > On 20 Jun 2016, at 21:36, Sergey Kuksenko wrote: >> >> Hi, >> >> Could you please review the following fix for JDK-8158690?

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 closes. > Same semantic i

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

> On 23 Jun 2016, at 15:36, Simone Bordet wrote: > > Hi, > > On Thu, Jun 23, 2016 at 3:58 PM, Chris Hegarty > wrote: >> At one point I thought the same, but after, yet another, re-reading of the >> RFC >> I disagree. The semantics are somewhat stron

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

On 23 Jun 2016, at 16:09, Simone Bordet wrote: > > Hi, > > On Thu, Jun 23, 2016 at 4:40 PM, Chris Hegarty > wrote: >> What Pavel is trying to do with onClose is to adhere to the >> spirit of the RFC, rather than supporting open-ended half-close semantics. > &

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 wrote: > > Sergey and I discuss this off-line and the potential performance improvement > here is very significant; raises performance from 25 request/sec to 6000 &g

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 think I kinda talked (off-l

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

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

Svetlana, >> The source code changes look fine. On the test... > On 11 Jul 2016, at 14:20, Daniel Fuchs wrote: > > Hi Svetlana, > > Have you thought of using a CountDownLatch (or some other > synchronization mechanism like e.g. Se

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 201

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: 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 *closed* socket. > You should

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 PM, Sergey Kuksenko wrote: >>

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

Re: JDK 9 RFR of JDK-8161565: Problem list httpclient/SplitResponse.java and URLPermission/URLTest.java

Amy, I approve the addition of SplitResponse to the ProblemList, but not URLTest. URLTest is too important a test to not be run, instead, I will send out an RFR, soon, to resolve the intermittent issue with the test itself. -Chris. > On 18 Jul 2016, at 06:48, Amy Lu wrote: > > Below tests hav

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

The test uses hardcoded port numbers for its listening HTTP and HTTPS severs. These hardcoded port numbers are problematic as the ports may not necessarily be available. The reason for the hardcoded port numbers is that the test uses a number of static, checked in, policy files, to grant ( and rest

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

at sun.net.www.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

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

advance Christoph -Original Message- From: Langer, Christoph Sent: Mittwoch, 13. Juli 2016 17:02 To: 'Chris Hegarty' Cc: net-dev@openjdk.java.net Subject: RE: RFR (S) JDK-8160174: java.net.NetworkInterface - fixes and improvements for network interface listing Hi Chris, ok, here

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 preci

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 number for a bug to the tes

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/ > Looks fine. -

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

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 with a really long bug >>> list

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 change [2] > that > caused th

Re: RFR (XXS): 8145732: Duplicate entry in http.nonProxyHosts will ignore subsequent entries - test update

> On 12 Aug 2016, at 15:07, Svetlana Nikandrova > wrote: > > Hello all, > > please review next micro test update. It turned out that code change for > JDK-8035158 also fixed problem described in JDK-8145732. > But I think It's worth it to update regression test with test case that > explici

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: http://cr.openjdk.java.net/~xiaofeya/8163561/webrev.00/

Re: [9] RFR: 8164592: java/net/MulticastSocket/NoLoopbackPackets.java tests may leave a daemon thread

On 23 Aug 2016, at 03:03, Artem Smotrakov wrote: > > Hello, > > Please review the following patch for NoLoopbackPackets.java test. > > The test starts a daemon thread which has an infinite loop. If jtreg uses the > same JVM to run multiple tests (agent VM), then this thread will be keep > run

Re: HTTP client API

On 23/08/16 22:19, Pavel Rappo wrote: http://cr.openjdk.java.net/~chegar/docs/sandbox.html And yes, 'http-client-branch' is the correct branch. -Chris. On 23 Aug 2016, at 21:20, Martin Buchholz wrote: I tried this: (Install mercurial trees extension.) hg tclone http://hg.openjdk.java.n

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 chang

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

is. > > Thanks, > Felix > On 2016/8/18 23:43, Chris Hegarty wrote: >> 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 c

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 point

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: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8165180/webrev.00/ This seems

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: > > http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/ca7fb78b94b6/src/java.httpclient/share/classes/java/net/http/SSLDele

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, would you mind to review i

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

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. Perhaps it would be bes

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 NET_R

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

at is fine. 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, >>

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

st 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 >>> NET_ReadWithTimeout

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

wards 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, V

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 a/test/java/net/SetFactoryPermission/SetFactoryPermission.java > b/te

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 tests has a reference to

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

;> 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 or to >>>&g

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 remote

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

;>>>>> >>>>>> Cc: >>>>>> net-dev@openjdk.java.net; Chris Hegarty >>>>>> >>>>>> Subject: Re: RFR 8075484:SocketInputStream.socketRead0 can hang even >>>>>> >>>> with >>>>

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 8153674: Expected SocketException not thrown when calling bind() with setReuseAddress(false)

explore an alternative, so see what it would look like. -Chris. regards Mark On 14/09/2016 11:43, Chris Hegarty wrote: 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 Webr

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

specific getter 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

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)

kets, 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

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 we don't know where the

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: 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. -Chris. > Issue: Several regres

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

Felix, > On 20 Sep 2016, at 13:57, Felix Yang wrote: > > Hi all, > please review the following test fix. It explicitly disables proxy to > make sure the test not affected by different environment configuration. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8166359 > > Webrev: >

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 wrote: Hi all, please review the following test fix. It explicitly disables proxy to make sure the test not affected by different environment

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 has not been update yet. I will d

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 triggering another MS curiosit

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 li

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

59410/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 wrote: it is good that you added the additional error code, "cover all bases", as they say. In any case your exc

Re: HTTP client API

On 22/09/16 08:54, Chris Hegarty wrote: 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(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 i

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