Re: RFR: 8193370 Provide more user friendly defaults for HTTP/2 client settings

Hi Simone, On 12/12/2017 21:02, Daniel Fuchs wrote: On 12/12/2017 18:21, Simone Bordet wrote: Our experience is that even in fast network (not localhost) 16 MiB session windows will hit TCP congestion control before stalling HTTP/2 flow control. I have experimented with 16Mib and 32Mib. Even

Re: RFR: 8193370 Provide more user friendly defaults for HTTP/2 client settings

Hi Simone, Long time no talk ;-) Thanks for sharing your experience! On 12/12/2017 18:21, Simone Bordet wrote: Our experience is that even in fast network (not localhost) 16 MiB session windows will hit TCP congestion control before stalling HTTP/2 flow control. I have experimented with 16Mi

Re: RFR: 8193370 Provide more user friendly defaults for HTTP/2 client settings

Hi, On Tue, Dec 12, 2017 at 7:04 PM, Chris Hegarty wrote: > >> On 12 Dec 2017, at 17:43, Daniel Fuchs wrote: >> >> Hi, >> >> please find below a patch for: >> >> 8193370 Provide more user friendly defaults for HTTP/2 client settings >> https://bugs.openjdk.java.net/browse/JDK-8193370 >> >> webre

Re: RFR: 8193370 Provide more user friendly defaults for HTTP/2 client settings

> On 12 Dec 2017, at 17:43, Daniel Fuchs wrote: > > Hi, > > please find below a patch for: > > 8193370 Provide more user friendly defaults for HTTP/2 client settings > https://bugs.openjdk.java.net/browse/JDK-8193370 > > webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8193370/webrev.01/

RFR: 8193370 Provide more user friendly defaults for HTTP/2 client settings

Hi, please find below a patch for: 8193370 Provide more user friendly defaults for HTTP/2 client settings https://bugs.openjdk.java.net/browse/JDK-8193370 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8193370/webrev.01/ best regards, -- daniel

Re: RFR: 8192966 HttpClient should reuse TCP connection for h2c connections

Thanks Daniel. I'm looking at this change again as I have noticed the behavior when multiple https requests are initiated might not be what we want. I'll post another webrev later. - Michael On 12/12/2017, 10:32, Daniel Fuchs wrote: Hi Michael, I wonder whether Http2Connection::closeStream wou

Re: RFR: 8193034: Optimize URL.toExternalForm

On 11/12/2017 17:24, Martin Buchholz wrote: There's now a Martin-style benchmark at http://cr.openjdk.java.net/~martin/webrevs/jdk/URLMicroBenchmark/ that suggests the code is ~ 25% faster with default JVM flags (C2) but ~ 25

Re: JEP 321: HTTP Client - Use of Flow.Subscriber and Flow.Publisher

I filed the following JIRA issue to track this discussion and proposal. https://bugs.openjdk.java.net/browse/JDK-8193365 I'll start the process of bringing it into 10, unless there are any final comments. FTR, I'm happy where we ended up on this. -Chris. On 11/12/17 15:48, Chris Hegarty wro

Re: RFR 8185027: Typo in java.net.URLClassLoader.findResources(String) method documentation

On 12/12/2017 10:40, Chris Hegarty wrote: - * @return an {@code Enumeration} of {@code URL}s - * If the loader is closed, the Enumeration will be empty. + * @return An {@code Enumeration} of {@code URL}s. + * If the loader is closed, the Enumeration contains no

Re: RFR 8185027: Typo in java.net.URLClassLoader.findResources(String) method documentation

On 12/12/17 10:36, Alan Bateman wrote: ... Looks fine. Separately, I don't know if "empty" is defined anywhere for Enumerations, it could just say "contains no elements" or other variants. That is better. diff --git a/src/java.base/share/classes/java/net/URLClassLoader.java b/src/java.base/

Re: RFR 8185027: Typo in java.net.URLClassLoader.findResources(String) method documentation

On 12/12/2017 10:27, Chris Hegarty wrote: The returns section of the java.net.URLClassLoader.findResources(String) method documentation, contains the following sentence:    "an Enumeration of URLs If the loader is closed, the Enumeration     will be empty." should be replaced by:    "An Enumerati

Re: RFR: 8192966 HttpClient should reuse TCP connection for h2c connections

Hi Michael, I wonder whether Http2Connection::closeStream would be a better place to call Stream::checkConnectionClosure? If not then shouldn't it be called in Stream::release as well? best regards, -- daniel On 12/12/2017 10:07, Michael McMahon wrote: http://cr.openjdk.java.net/~michaelm/81

Re: RFR: 8193034: Optimize URL.toExternalForm

Martin, I think your changes are good. Thanks for sharing your benchmark and results. -Chris. On 11/12/17 17:24, Martin Buchholz wrote: There's now a Martin-style benchmark at http://cr.openjdk.java.net/~martin/webrevs/jdk/URLMicroBenchmark/ that suggests the code is ~ 25% faster with default

RFR 8185027: Typo in java.net.URLClassLoader.findResources(String) method documentation

The returns section of the java.net.URLClassLoader.findResources(String) method documentation, contains the following sentence: "an Enumeration of URLs If the loader is closed, the Enumeration will be empty." should be replaced by: "An Enumeration of URLs. If the loader is closed, the En

RFR: 8192966 HttpClient should reuse TCP connection for h2c connections

http://cr.openjdk.java.net/~michaelm/8192966/webrev.1/ Thanks, Michael.