From chris.hegarty at oracle.com Wed Feb 1 13:33:38 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 1 Feb 2017 13:33:38 +0000 Subject: RFR:8170868: DefaultProxySelector should use system defaults on Windows, MacOS and Gnome In-Reply-To: <2fdab8ff784d4a0ba394f464fa53c8a0@DEROTE13DE06.global.corp.sap> References: <76e26ae6-dac6-5dd0-fc7d-6466bcbb084b@oracle.com> <8d0ff2a31d2242d89abad104ac9d8a07@DEROTE13DE10.global.corp.sap> <4453986b-e8d9-e045-d282-eca878982cca@oracle.com> <81525c687eeb410ba72060e4c336cca9@DEROTE13DE10.global.corp.sap> <2A66AE32-7A99-40B9-8576-6E14571E6622@oracle.com> <347b81bb-abf1-b084-3caa-38bced201b03@oracle.com> <436f383c-0feb-67b4-267f-ce4f005e8868@oracle.com> <2fdab8ff784d4a0ba394f464fa53c8a0@DEROTE13DE06.global.corp.sap> Message-ID: > 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 suggested by Erik remove the unnecessary exclude. 2) As I suggested off-line add a timeout for badly configured systems where the PAC URL cannot be retrieved in a timely manner. If you need a sponsor I can push this for you, otherwise I think I?m done with the review. Thanks for your patience. --- diff -r 4432850b8099 make/lib/NetworkingLibraries.gmk --- a/make/lib/NetworkingLibraries.gmk Tue Jan 31 13:12:14 2017 +0100 +++ b/make/lib/NetworkingLibraries.gmk Wed Feb 01 13:29:28 2017 +0000 @@ -25,16 +25,11 @@ LIBNET_SRC_DIRS := $(call FindSrcDirsForLib, java.base, net) -ifeq ($(OPENJDK_TARGET_OS), macosx) - LIBNET_EXCLUDE_FILES := $(JDK_TOPDIR)/src/java.base/unix/native/libnet/DefaultProxySelector.c -endif - $(eval $(call SetupNativeCompilation,BUILD_LIBNET, \ LIBRARY := net, \ OUTPUT_DIR := $(INSTALL_LIBRARIES_HERE), \ SRC := $(LIBNET_SRC_DIRS), \ OPTIMIZATION := LOW, \ - EXCLUDE_FILES := $(LIBNET_EXCLUDE_FILES), \ CFLAGS := $(CFLAGS_JDKLIB) -I$(SUPPORT_OUTPUTDIR)/headers/java.base \ $(LIBJAVA_HEADER_FLAGS) $(addprefix -I, $(LIBNET_SRC_DIRS)), \ DISABLED_WARNINGS_gcc := format-nonliteral, \ diff -r 4432850b8099 src/java.base/macosx/native/libnet/DefaultProxySelector.c --- a/src/java.base/macosx/native/libnet/DefaultProxySelector.c Tue Jan 31 13:12:14 2017 +0100 +++ b/src/java.base/macosx/native/libnet/DefaultProxySelector.c Wed Feb 01 13:29:28 2017 +0000 @@ -102,6 +102,7 @@ CFURLRef scriptURL; CFTypeRef result = NULL; CFStreamClientContext context = { 0, &result, NULL, NULL, NULL }; + CFTimeInterval timeout = 5; scriptURL = CFDictionaryGetValue(currentProxy, kCFProxyAutoConfigurationURLKey); @@ -114,7 +115,7 @@ * release the return CFRunLoopSourceRef . */ CFRunLoopAddSource(CFRunLoopGetCurrent(), runLoop, kResolveProxyRunLoopMode); - CFRunLoopRunInMode(kResolveProxyRunLoopMode, 1.0e10, false); + CFRunLoopRunInMode(kResolveProxyRunLoopMode, timeout, false); CFRunLoopRemoveSource(CFRunLoopGetCurrent(), runLoop, kResolveProxyRunLoopMode); /* -Chris. From daniel.fuchs at oracle.com Thu Feb 2 16:11:43 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 2 Feb 2017 16:11:43 +0000 Subject: RFR: 8173315: java/net/HttpURLConnection/SetAuthenticator/HTTPSetAuthenticatorTest.java fails intermittently Message-ID: <8b8f8ca7-9614-5fca-3aa6-ed7fe68a1115@oracle.com> Hi, Please find below a fix for: 8173315: java/net/HttpURLConnection/SetAuthenticator/HTTPSetAuthenticatorTest.java fails intermittently https://bugs.openjdk.java.net/browse/JDK-8173315 After examining the logs it appears that the problem may be due to reusing a dynamically allocated local port number in the same VM. This happens very rarely, only when the OS starts dealing previously allocated (and released) port numbers for port 0. http://cr.openjdk.java.net/~dfuchs/webrev_8173315/webrev.00/ best regards, -- daniel From michael.x.mcmahon at oracle.com Thu Feb 2 18:08:59 2017 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Thu, 02 Feb 2017 18:08:59 +0000 Subject: RFR: 8173315: java/net/HttpURLConnection/SetAuthenticator/HTTPSetAuthenticatorTest.java fails intermittently In-Reply-To: <8b8f8ca7-9614-5fca-3aa6-ed7fe68a1115@oracle.com> References: <8b8f8ca7-9614-5fca-3aa6-ed7fe68a1115@oracle.com> Message-ID: <589375BB.9010205@oracle.com> Hi Daniel, I understand that there is a further dependency on the static authentication cache and it is important to have a port number that is not only unbound, but also not previously used in the same test VM. It might be worth adding a comment to that effect in the change. Otherwise, the fix looks good. Thanks, Michael On 02/02/2017, 16:11, Daniel Fuchs wrote: > Hi, > > Please find below a fix for: > > 8173315: > java/net/HttpURLConnection/SetAuthenticator/HTTPSetAuthenticatorTest.java > fails intermittently > https://bugs.openjdk.java.net/browse/JDK-8173315 > > After examining the logs it appears that the problem may > be due to reusing a dynamically allocated local port number > in the same VM. > This happens very rarely, only when the OS starts dealing > previously allocated (and released) port numbers for port 0. > > http://cr.openjdk.java.net/~dfuchs/webrev_8173315/webrev.00/ > > best regards, > > -- daniel From daniel.fuchs at oracle.com Thu Feb 2 18:29:06 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 2 Feb 2017 18:29:06 +0000 Subject: RFR: 8173315: java/net/HttpURLConnection/SetAuthenticator/HTTPSetAuthenticatorTest.java fails intermittently In-Reply-To: <589375BB.9010205@oracle.com> References: <8b8f8ca7-9614-5fca-3aa6-ed7fe68a1115@oracle.com> <589375BB.9010205@oracle.com> Message-ID: <6537d1b0-d4dd-4084-ee3c-ed4190bb4c23@oracle.com> On 02/02/17 18:08, Michael McMahon wrote: > Hi Daniel, > > I understand that there is a further dependency on the static > authentication cache > and it is important to have a port number that is not only unbound, but > also not previously used > in the same test VM. It might be worth adding a comment to that effect > in the change. > Otherwise, the fix looks good. Thanks Michael! Here is the new webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8173315/webrev.00/ -- daniel > > Thanks, > Michael > > On 02/02/2017, 16:11, Daniel Fuchs wrote: >> Hi, >> >> Please find below a fix for: >> >> 8173315: >> java/net/HttpURLConnection/SetAuthenticator/HTTPSetAuthenticatorTest.java >> fails intermittently >> https://bugs.openjdk.java.net/browse/JDK-8173315 >> >> After examining the logs it appears that the problem may >> be due to reusing a dynamically allocated local port number >> in the same VM. >> This happens very rarely, only when the OS starts dealing >> previously allocated (and released) port numbers for port 0. >> >> http://cr.openjdk.java.net/~dfuchs/webrev_8173315/webrev.00/ >> >> best regards, >> >> -- daniel From daniel.fuchs at oracle.com Thu Feb 2 18:30:10 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 2 Feb 2017 18:30:10 +0000 Subject: RFR: 8173315: java/net/HttpURLConnection/SetAuthenticator/HTTPSetAuthenticatorTest.java fails intermittently In-Reply-To: <6537d1b0-d4dd-4084-ee3c-ed4190bb4c23@oracle.com> References: <8b8f8ca7-9614-5fca-3aa6-ed7fe68a1115@oracle.com> <589375BB.9010205@oracle.com> <6537d1b0-d4dd-4084-ee3c-ed4190bb4c23@oracle.com> Message-ID: On 02/02/17 18:29, Daniel Fuchs wrote: > Here is the new webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8173315/webrev.00/ I meant http://cr.openjdk.java.net/~dfuchs/webrev_8173315/webrev.01/ of course :-( -- daniel From michael.x.mcmahon at oracle.com Fri Feb 3 10:45:10 2017 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Fri, 03 Feb 2017 10:45:10 +0000 Subject: RFR: 8173315: java/net/HttpURLConnection/SetAuthenticator/HTTPSetAuthenticatorTest.java fails intermittently In-Reply-To: References: <8b8f8ca7-9614-5fca-3aa6-ed7fe68a1115@oracle.com> <589375BB.9010205@oracle.com> <6537d1b0-d4dd-4084-ee3c-ed4190bb4c23@oracle.com> Message-ID: <58945F36.9000603@oracle.com> Looks fine Daniel. Thanks, Michael On 02/02/2017, 18:30, Daniel Fuchs wrote: > On 02/02/17 18:29, Daniel Fuchs wrote: >> Here is the new webrev: >> http://cr.openjdk.java.net/~dfuchs/webrev_8173315/webrev.00/ > > I meant > http://cr.openjdk.java.net/~dfuchs/webrev_8173315/webrev.01/ > of course :-( > > -- daniel From michael.x.mcmahon at oracle.com Fri Feb 10 09:35:08 2017 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Fri, 10 Feb 2017 09:35:08 +0000 Subject: RFR: JDK-8174716,,java/net/httpclient/security/Driver.java failing in JDK 9 Message-ID: <589D894C.6060007@oracle.com> This test has been failing since the introduction of the incubator mechanism but wasn't being run due to an issue with jtreg that is about to be fixed. This fixes the problem with the test first. http://cr.openjdk.java.net/~michaelm/8174716/webrev.1/ Thanks, Michael. From Alan.Bateman at oracle.com Fri Feb 10 09:36:33 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 10 Feb 2017 09:36:33 +0000 Subject: RFR: JDK-8174716,,java/net/httpclient/security/Driver.java failing in JDK 9 In-Reply-To: <589D894C.6060007@oracle.com> References: <589D894C.6060007@oracle.com> Message-ID: <69995b1f-03b0-cc8d-f6cd-4b948d63f5ab@oracle.com> Looks okay. On 10/02/2017 09:35, Michael McMahon wrote: > This test has been failing since the introduction of the incubator > mechanism > but wasn't being run due to an issue with jtreg that is about to be > fixed. > > This fixes the problem with the test first. > > http://cr.openjdk.java.net/~michaelm/8174716/webrev.1/ > > Thanks, > > Michael. From daniel.fuchs at oracle.com Fri Feb 10 10:14:53 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 10 Feb 2017 10:14:53 +0000 Subject: RFR: JDK-8174716,,java/net/httpclient/security/Driver.java failing in JDK 9 In-Reply-To: <589D894C.6060007@oracle.com> References: <589D894C.6060007@oracle.com> Message-ID: <27e73504-d114-7b47-ec65-8c0f66f3e9a5@oracle.com> Looks good Michael. But I'm afraid the use of Utils.getFreePort() means we might continue to see this test failing intermittently now and then. best regards, -- daniel On 10/02/17 09:35, Michael McMahon wrote: > This test has been failing since the introduction of the incubator > mechanism > but wasn't being run due to an issue with jtreg that is about to be fixed. > > This fixes the problem with the test first. > > http://cr.openjdk.java.net/~michaelm/8174716/webrev.1/ > > Thanks, > > Michael. From michael.x.mcmahon at oracle.com Fri Feb 10 17:10:14 2017 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Fri, 10 Feb 2017 17:10:14 +0000 Subject: RFR 8174745: Httpclient source update for JDK 8 Message-ID: <589DF3F6.8070905@oracle.com> Hi Could I get the following change reviewed please? It is an update to the httpclient code to make it easier to backport to JDK 8 for testing purposes. http://cr.openjdk.java.net/~michaelm/8174745/webrev.1/index.html Thanks, Michael From daniel.fuchs at oracle.com Fri Feb 10 18:00:24 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 10 Feb 2017 18:00:24 +0000 Subject: RFR 8174745: Httpclient source update for JDK 8 In-Reply-To: <589DF3F6.8070905@oracle.com> References: <589DF3F6.8070905@oracle.com> Message-ID: <79ec861d-faa9-9d78-2de7-2270c98706ee@oracle.com> Hi Michael, Looks good to me. best regards, -- daniel On 10/02/17 17:10, Michael McMahon wrote: > Hi > > Could I get the following change reviewed please? > > It is an update to the httpclient code to make it easier to backport to > JDK 8 > for testing purposes. > > http://cr.openjdk.java.net/~michaelm/8174745/webrev.1/index.html > > Thanks, > Michael From daniel.fuchs at oracle.com Mon Feb 13 16:31:33 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 13 Feb 2017 16:31:33 +0000 Subject: RFR 8174833: java/net/httpclient/http2/BasicTest.java always fails but always report success Message-ID: <7081b6ca-e2fc-01c7-eaeb-9136c0b2bafb@oracle.com> Hi, Please find below an almost trivial fix for an HTTP/2 test bug: 8174833: java/net/httpclient/http2/BasicTest.java always fails but always report success https://bugs.openjdk.java.net/browse/JDK-8174833 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8174833/webrev.00/ best regards, -- daniel From michael.x.mcmahon at oracle.com Mon Feb 13 16:34:21 2017 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 13 Feb 2017 16:34:21 +0000 Subject: RFR 8174833: java/net/httpclient/http2/BasicTest.java always fails but always report success In-Reply-To: <7081b6ca-e2fc-01c7-eaeb-9136c0b2bafb@oracle.com> References: <7081b6ca-e2fc-01c7-eaeb-9136c0b2bafb@oracle.com> Message-ID: <58A1E00D.5040600@oracle.com> Good catch Daniel. Looks good. Thanks, Michael. On 13/02/2017, 16:31, Daniel Fuchs wrote: > Hi, > > Please find below an almost trivial fix for an HTTP/2 test bug: > > 8174833: java/net/httpclient/http2/BasicTest.java always fails > but always report success > https://bugs.openjdk.java.net/browse/JDK-8174833 > > webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8174833/webrev.00/ > > best regards, > > -- daniel From chris.hegarty at oracle.com Mon Feb 20 16:14:18 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 20 Feb 2017 16:14:18 +0000 Subject: RFR [9] 8175261: Per-protocol setting for not working for JAR URLConnection defaultUseCaches Message-ID: <8cb9c2fb-e7c3-056a-bbd9-426a92272cf3@oracle.com> 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 jar file URLConnection. This means any attempt to control caching for just JAR URLs fails. "jar" always ends up being treated like whatever the embedded URL is, which is exactly the case that 8163449 was trying to address. JarURLConnection should set the initial cache value of its emdedded URLConnection ( to the actual resource ), to whatever its initial value is. Subsequent set/getUseCaches will then behave as expected. http://cr.openjdk.java.net/~chegar/8175261.00/ https://bugs.openjdk.java.net/browse/JDK-8175261 -Chris [1] https://bugs.openjdk.java.net/browse/JDK-8163449 From michael.x.mcmahon at oracle.com Mon Feb 20 16:46:52 2017 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 20 Feb 2017 16:46:52 +0000 Subject: RFR 8175274 Fix httpclient asynchronous usage Message-ID: <58AB1D7C.7050404@oracle.com> Could I get the following httpclient change reviewed please? http://cr.openjdk.java.net/~michaelm/8175274/webrev.1/ It fixes some issues with asynchronous requests. Thanks, Michael. From daniel.fuchs at oracle.com Tue Feb 21 10:24:28 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 21 Feb 2017 10:24:28 +0000 Subject: RFR 8175274 Fix httpclient asynchronous usage In-Reply-To: <58AB1D7C.7050404@oracle.com> References: <58AB1D7C.7050404@oracle.com> Message-ID: <48601a34-16c3-05ff-ff9c-953eec6bf657@oracle.com> On 20/02/17 16:46, Michael McMahon wrote: > Could I get the following httpclient change reviewed please? > > http://cr.openjdk.java.net/~michaelm/8175274/webrev.1/ Hi Michael, Looks good to me. Nice to see this patch getting in. best regards, -- daniel > > It fixes some issues with asynchronous requests. > > Thanks, > Michael. > From pavel.rappo at oracle.com Tue Feb 21 16:01:35 2017 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Tue, 21 Feb 2017 16:01:35 +0000 Subject: RFR 8175305: Typos in net.properties Message-ID: Hello, Could you please review the following trivial change for [1]? http://cr.openjdk.java.net/~prappo/8175305/webrev.00/ Thanks, -Pavel -------------------------------------------------------------------------------- [1] https://bugs.openjdk.java.net/browse/JDK-8175305 From brian.burkhalter at oracle.com Tue Feb 21 16:06:19 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 21 Feb 2017 08:06:19 -0800 Subject: RFR 8175305: Typos in net.properties In-Reply-To: References: Message-ID: +1 On Feb 21, 2017, at 8:01 AM, Pavel Rappo wrote: > Hello, > > Could you please review the following trivial change for [1]? > > http://cr.openjdk.java.net/~prappo/8175305/webrev.00/ > > Thanks, > -Pavel > > -------------------------------------------------------------------------------- > [1] https://bugs.openjdk.java.net/browse/JDK-8175305 > From michael.x.mcmahon at oracle.com Wed Feb 22 11:02:26 2017 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 22 Feb 2017 11:02:26 +0000 Subject: RFR [9] 8175261: Per-protocol setting for not working for JAR URLConnection defaultUseCaches In-Reply-To: <8cb9c2fb-e7c3-056a-bbd9-426a92272cf3@oracle.com> References: <8cb9c2fb-e7c3-056a-bbd9-426a92272cf3@oracle.com> Message-ID: <58AD6FC2.405@oracle.com> Looks good Chris. - Michael. On 20/02/2017, 16:14, Chris Hegarty wrote: > 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 > jar file URLConnection. This means any attempt to control caching for > just JAR URLs fails. "jar" always ends up being treated like whatever > the embedded URL is, which is exactly the case that 8163449 was trying > to address. > > JarURLConnection should set the initial cache value of its emdedded > URLConnection ( to the actual resource ), to whatever its initial > value is. Subsequent set/getUseCaches will then behave as expected. > > http://cr.openjdk.java.net/~chegar/8175261.00/ > https://bugs.openjdk.java.net/browse/JDK-8175261 > > -Chris > > [1] https://bugs.openjdk.java.net/browse/JDK-8163449 From daniel.fuchs at oracle.com Wed Feb 22 13:40:59 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 22 Feb 2017 13:40:59 +0000 Subject: RFR [9] 8175261: Per-protocol setting for not working for JAR URLConnection defaultUseCaches In-Reply-To: <8cb9c2fb-e7c3-056a-bbd9-426a92272cf3@oracle.com> References: <8cb9c2fb-e7c3-056a-bbd9-426a92272cf3@oracle.com> Message-ID: <91a2976e-3e06-b78f-a2b7-da507847a896@oracle.com> Hi Chris, Looks good to me as well. cheers, -- daniel On 20/02/17 16:14, Chris Hegarty wrote: > 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 > jar file URLConnection. This means any attempt to control caching for > just JAR URLs fails. "jar" always ends up being treated like whatever > the embedded URL is, which is exactly the case that 8163449 was trying > to address. > > JarURLConnection should set the initial cache value of its emdedded > URLConnection ( to the actual resource ), to whatever its initial > value is. Subsequent set/getUseCaches will then behave as expected. > > http://cr.openjdk.java.net/~chegar/8175261.00/ > https://bugs.openjdk.java.net/browse/JDK-8175261 > > -Chris > > [1] https://bugs.openjdk.java.net/browse/JDK-8163449 From pavel.rappo at oracle.com Thu Feb 23 14:02:36 2017 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Thu, 23 Feb 2017 14:02:36 +0000 Subject: RFR[9] 8164625: Pooled HttpConnection should be removed during close Message-ID: Hello, Could you please review the following change for [1]? http://cr.openjdk.java.net/~prappo/8164625/webrev.00/ This patch addresses the root cause of the problem. Namely, HTTP connections used by requests made on behalf of the WebSocket (i.e. Opening Handshake) are no longer returned to the connection pool. The provided test reproduces the scenario described in the related issue. Thanks, -Pavel -------------------------------------------------------------------------------- [1] https://bugs.openjdk.java.net/browse/JDK-8164625 From michael.x.mcmahon at oracle.com Thu Feb 23 17:31:20 2017 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Thu, 23 Feb 2017 17:31:20 +0000 Subject: RFR[9] 8164625: Pooled HttpConnection should be removed during close In-Reply-To: References: Message-ID: <58AF1C68.9000903@oracle.com> Hi Pavel The source change looks fine. I'm not sure how the test works though. How does it check that the connection is not retained? Michael. On 23/02/2017, 14:02, Pavel Rappo wrote: > Hello, > > Could you please review the following change for [1]? > > http://cr.openjdk.java.net/~prappo/8164625/webrev.00/ > > This patch addresses the root cause of the problem. Namely, HTTP connections > used by requests made on behalf of the WebSocket (i.e. Opening Handshake) are no > longer returned to the connection pool. The provided test reproduces the > scenario described in the related issue. > > Thanks, > -Pavel > > -------------------------------------------------------------------------------- > [1] https://bugs.openjdk.java.net/browse/JDK-8164625 > From daniel.fuchs at oracle.com Thu Feb 23 17:40:30 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 23 Feb 2017 17:40:30 +0000 Subject: RFR[9] 8164625: Pooled HttpConnection should be removed during close In-Reply-To: <58AF1C68.9000903@oracle.com> References: <58AF1C68.9000903@oracle.com> Message-ID: On 23/02/17 17:31, Michael McMahon wrote: > Hi Pavel > > The source change looks fine. I'm not sure how the test works though. > How does it check that the connection is not retained? I agree with Michael. A small comment in the test main() to explain what's going on and what's being tested would be nice. best regards, -- daniel > > Michael. > > On 23/02/2017, 14:02, Pavel Rappo wrote: >> Hello, >> >> Could you please review the following change for [1]? >> >> http://cr.openjdk.java.net/~prappo/8164625/webrev.00/ >> >> This patch addresses the root cause of the problem. Namely, HTTP >> connections >> used by requests made on behalf of the WebSocket (i.e. Opening >> Handshake) are no >> longer returned to the connection pool. The provided test reproduces the >> scenario described in the related issue. >> >> Thanks, >> -Pavel >> >> -------------------------------------------------------------------------------- >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8164625 >> From pavel.rappo at oracle.com Fri Feb 24 10:28:44 2017 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Fri, 24 Feb 2017 10:28:44 +0000 Subject: RFR[9] 8164625: Pooled HttpConnection should be removed during close In-Reply-To: <58AF1C68.9000903@oracle.com> References: <58AF1C68.9000903@oracle.com> Message-ID: <29FC09C0-01A8-4E1D-A4C8-C4F92C8A6D93@oracle.com> Michael, Daniel, updated in place. Thanks, -Pavel > On 23 Feb 2017, at 17:31, Michael McMahon wrote: > > Hi Pavel > > The source change looks fine. I'm not sure how the test works though. > How does it check that the connection is not retained? > > Michael. > > On 23/02/2017, 14:02, Pavel Rappo wrote: >> Hello, >> >> Could you please review the following change for [1]? >> >> http://cr.openjdk.java.net/~prappo/8164625/webrev.00/ >> >> This patch addresses the root cause of the problem. Namely, HTTP connections >> used by requests made on behalf of the WebSocket (i.e. Opening Handshake) are no >> longer returned to the connection pool. The provided test reproduces the >> scenario described in the related issue. >> >> Thanks, >> -Pavel >> >> -------------------------------------------------------------------------------- >> [1] https://bugs.openjdk.java.net/browse/JDK-8164625 >> From michael.x.mcmahon at oracle.com Fri Feb 24 10:54:34 2017 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Fri, 24 Feb 2017 10:54:34 +0000 Subject: RFR[9] 8164625: Pooled HttpConnection should be removed during close In-Reply-To: <29FC09C0-01A8-4E1D-A4C8-C4F92C8A6D93@oracle.com> References: <58AF1C68.9000903@oracle.com> <29FC09C0-01A8-4E1D-A4C8-C4F92C8A6D93@oracle.com> Message-ID: <58B010EA.8050001@oracle.com> That looks fine to me now. Thanks, Michael On 24/02/2017, 10:28, Pavel Rappo wrote: > Michael, Daniel, > > updated in place. > > Thanks, > -Pavel > >> On 23 Feb 2017, at 17:31, Michael McMahon wrote: >> >> Hi Pavel >> >> The source change looks fine. I'm not sure how the test works though. >> How does it check that the connection is not retained? >> >> Michael. >> >> On 23/02/2017, 14:02, Pavel Rappo wrote: >>> Hello, >>> >>> Could you please review the following change for [1]? >>> >>> http://cr.openjdk.java.net/~prappo/8164625/webrev.00/ >>> >>> This patch addresses the root cause of the problem. Namely, HTTP connections >>> used by requests made on behalf of the WebSocket (i.e. Opening Handshake) are no >>> longer returned to the connection pool. The provided test reproduces the >>> scenario described in the related issue. >>> >>> Thanks, >>> -Pavel >>> >>> -------------------------------------------------------------------------------- >>> [1] https://bugs.openjdk.java.net/browse/JDK-8164625 >>> From daniel.fuchs at oracle.com Fri Feb 24 12:11:04 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 24 Feb 2017 12:11:04 +0000 Subject: RFR[9] 8164625: Pooled HttpConnection should be removed during close In-Reply-To: <29FC09C0-01A8-4E1D-A4C8-C4F92C8A6D93@oracle.com> References: <58AF1C68.9000903@oracle.com> <29FC09C0-01A8-4E1D-A4C8-C4F92C8A6D93@oracle.com> Message-ID: <2de0468f-0ed5-1e49-6bf2-a5df07563493@oracle.com> On 24/02/17 10:28, Pavel Rappo wrote: > Michael, Daniel, > > updated in place. Looks good Pavel. cheers, -- daniel > > Thanks, > -Pavel > >> On 23 Feb 2017, at 17:31, Michael McMahon wrote: >> >> Hi Pavel >> >> The source change looks fine. I'm not sure how the test works though. >> How does it check that the connection is not retained? >> >> Michael. >> >> On 23/02/2017, 14:02, Pavel Rappo wrote: >>> Hello, >>> >>> Could you please review the following change for [1]? >>> >>> http://cr.openjdk.java.net/~prappo/8164625/webrev.00/ >>> >>> This patch addresses the root cause of the problem. Namely, HTTP connections >>> used by requests made on behalf of the WebSocket (i.e. Opening Handshake) are no >>> longer returned to the connection pool. The provided test reproduces the >>> scenario described in the related issue. >>> >>> Thanks, >>> -Pavel >>> >>> -------------------------------------------------------------------------------- >>> [1] https://bugs.openjdk.java.net/browse/JDK-8164625 >>> >