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

Thanks. Pushed: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ac3e32924dfb -Chris. > On 8 Jun 2016, at 15:07, Langer, Christoph wrote: > > Hi Chris, > > I now took time to look at your proposal based on ioctl calls. This looks > very good. I came up with some modifications to your patch and c

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

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 [9] 8041924: [TESTBUG] sun/net/www/http/ChunkedOutputStream/checkError.java fails on some systems

Nice clean up Chris. Looks fine. Regards, Sean. On 09/06/16 20:49, Chris Hegarty wrote: 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

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-8157273: Simplify outgoing messages queueing policy in WebSocket API

Hi, On Sat, Jun 11, 2016 at 1:20 PM, Pavel Rappo wrote: > Simone, > > What's your opinion on how send(Ping|Pong|Close) should work? I mean with "one > outstanding send" policy you're advocating for, should all types of messages > sent by an app honor this policy? > > If we allow Pings, unsolicite

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

> On 13 Jun 2016, at 12:14, Simone Bordet wrote: > > To me, pings (let's leave out unsolicited pongs) are an application > mean to measure roundtrip; because they can be interleaved at the > protocol level, I may be interested in knowing when they are fully > written, but I would not make this i

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

Hi, On Mon, Jun 13, 2016 at 1:44 PM, Pavel Rappo wrote: > If you're talking about the application scheduling these Pings every X > seconds, > then I have a question. Are we talking about constant rate here or constant > delay? If it's the former, then I wonder what the application should do if t

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

Hi, On Mon, Jun 13, 2016 at 3:40 PM, Pavel Rappo wrote: > >> On 13 Jun 2016, at 12:14, Simone Bordet wrote: >> >> Close should definitely *not* "jump ahead of the queue", it should be >> sent after queued stuff has been sent. > > Why is that? Because contrary to ping, the specification does not

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

> On 13 Jun 2016, at 12:14, Simone Bordet wrote: > > Close should definitely *not* "jump ahead of the queue", it should be > sent after queued stuff has been sent. Why is that? Shouldn't we treat this as an implementation specific detail? I mean Close, Ping and Pong are control messages. They a

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

> On 13 Jun 2016, at 14:45, Simone Bordet wrote: > > Because contrary to ping, the specification does not say "as soon as > possible" but: > > "An endpoint MAY delay sending a Close frame until its current message is > sent (for instance, if the majority of a fragmented message is > already sen

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

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. Naoto On 6/13/16 3:29 AM, Pavel Rappo wrote: Hi, Could you please review the following change for JDK-8159039? http://cr.openjdk.java.net/~prappo/8

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-8159039: sun/net/httpclient/hpack/HeaderTableTest.java fails on some locales

Does that mean each method test invocation on an separate vm, or the scope is .java? If it's the latter, I would still suggest doing try/finally, otherwise the later test invocations could be affected with the FRENCH locale. Naoto On 6/13/16 8:52 AM, Chris Hegarty wrote: On 13/06/16 16:39, N

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

Hi All, Please review the below fix. Bug : JDK-8144008 Setting NO_PROXY on an URLConnection is not complied with Webrev : http://cr.openjdk.java.net/~vtewari/8144008/webrev0.0/index.html Thanks, Vyom