From dfuchs at openjdk.org Thu Jun 1 11:09:37 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 1 Jun 2023 11:09:37 GMT Subject: RFR: 8309200: java/net/httpclient/ExecutorShutdown fais intermittently, if connection closed during upgrade [v2] In-Reply-To: References: Message-ID: > The ExecutorShutdown test has been observed failing intermittently, notably if by misfortune the shutdown sequence causes a connection to get aborted while upgrading. The issue is that the `ConnectionAborter` class that allows to mark the connection as being scheduled for closing before a handle to the connection is actually available isn't forwarding the original exception for which closing the connection was requested. When the connection is eventually closed, a generic `IOException: connection closed locally` is raised at the `SocketTube` level, which unfortunately can race with the original cause. > > The fix makes it possible to relay the original cause to the place where the IOException is raised, in order to set it as the cause of the new exception. Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision: Review feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14251/files - new: https://git.openjdk.org/jdk/pull/14251/files/5f275916..5fb0731e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14251&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14251&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14251.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14251/head:pull/14251 PR: https://git.openjdk.org/jdk/pull/14251 From duke at openjdk.org Thu Jun 1 17:07:06 2023 From: duke at openjdk.org (Terry Chow) Date: Thu, 1 Jun 2023 17:07:06 GMT Subject: RFR: 8308593: Add Keepalive Extended Socket Options Support for Windows In-Reply-To: <7yOv2rc-pawQNLJSkjIU_fP2Z0hofqh1SMvN0dihFUk=.75f29eed-dbc0-48b6-8e59-86750691e6c1@github.com> References: <7yOv2rc-pawQNLJSkjIU_fP2Z0hofqh1SMvN0dihFUk=.75f29eed-dbc0-48b6-8e59-86750691e6c1@github.com> Message-ID: On Tue, 30 May 2023 22:46:05 GMT, Terry Chow wrote: > The PR adds support for setting the keepalive extended socket options on Windows. The implemented native code uses the SIO_KEEPALIVE_VALS control code, which is how keepalive values are set on Windows and so there are a few caveats. > > 1. The keepalive time and keepalive interval must both be set at the same time. In the implementation, a new SioKeepAlive class and ExtendedSocketOptions is created to capture this behaviour for Windows only. Keepalive enablement must also be configured when using SIO_KEEPALIVE_VALS, and so by default when setting keepalive time and keepalive interval, > keepalive will automatically be enabled. > > [SIO_KEEPALIVE_VALS doc](https://learn.microsoft.com/en-us/windows/win32/winsock/sio-keepalive-vals) > > 2. It doesn't seem possible to acquire the Keepalive time and keepalive interval values on Windows. So, the implementation doesn't support acquiring the values. > > https://stackoverflow.com/questions/14197347/how-to-query-socket-keep-alive-values-using-winsock/14198462#14198462 > https://stackoverflow.com/questions/18391341/reading-sio-keepalive-vals-fields-on-a-windows-socket-for-keepalive-idle-and-in > > 3. Keepalive probes are not supported. On Windows Vista and later, the number of keep-alive probes is set to 10 and cannot be changed. > > [SIO_KEEPALIVE_VALS Remarks](https://learn.microsoft.com/en-us/windows/win32/winsock/sio-keepalive-vals#remarks) > > For testing, I've updated the existing keepalive tests. But, since it's not possible to acquire the keepalive values on Windows to verify, I've indirectly tested setting the keepalive values by confirming keepalive is enabled where possible (since keepalive is enabled also when keepalive values are set). Apologies, I was talking to my liaison on what's the appropriate way to communicate (as I don't have a JBS account). Let me know if it's alright to discuss things here. Thanks for the quick reply on your thoughts. >The proposal that you have here is a new Windows specific and JDK-specific socket option that requires a lot of thinking about before going that route. I had similar thoughts as well, that this implementation was more of a "last resort". I've had other ideas of ways to go about this that I'll mention below, but there were some contentions and so this implementation was the most straightforward to do to get something working in order to have open dialog. But yeah, absolutely agree on more discussion. >It would be useful to know if the semantics of the SIO_KEEPALIVE_VALS control code is the equivalent of the TCP_KEEPIDLE + TCP_KEEPINTERVAL on other platforms. Yes, that's correct. SIO_KEEPALIVE_VALS is the Windows equivalent of setting the keep alive values on a per socket basis (only difference is that both are set at the same time). > It would also be useful to know if Windows has a system-wide default value for both the keep alive idle and interval. If it does then it might be possible to use the existing extended options, which if under the covers that both need to be set at the same time. So, the system-wide default keep alive idle and interval for Windows is 2hrs and 1s respectively. I also thought of using default values, but the issue is this: defaultKeepAliveTime = 2hrs defaultKeepAliveInterval = 1s 1. setKeepAliveTime(1hr) // user sets the keepAliveTime 2. setKeepAlive(1hr, defaultKeepAliveInterval) // under the covers we set both values 3. setKeepAliveInterval(20s) // user later sets the interval time 4. setKeepAlive(defaultKeepAliveTime, 20s) // prior keepAliveTime of 1hr is now back to default But we can get around this by keeping track of the current set keepAlive values. defaultKeepAliveTime = 2hrs defaultKeepAliveInterval = 1s currentKeepAliveTime = defaultKeepAliveTime currentKeepAliveInterval = defaultKeepAliveInterval 1. setKeepAliveTime(1hr) // user sets the keepAliveTime 2. setKeepAlive(1hr, currentKeepAliveInterval) // under the covers we set both values, keep track of new keepAliveTime value currentKeepAliveTime = 1hr 3. setKeepAliveInterval(20s) // user later sets the interval time 4. setKeepAlive(currentKeepAliveTime, 20s) // use prior set keepAliveTime currentKeepAliveInterval = 20s However, we can't keep track of the current keep alive values in `WindowsSocketOptions` as the same instance is shared by all socket instances. The place that makes the most sense to keep track of the current keep alive values seems like at the socket class level. What are your thoughts on keeping track of the values at the socket level? I was hesistant on this route because it doesn't seem right to track Windows only keep alive values at the socket class level. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14232#issuecomment-1572442618 From dfuchs at openjdk.org Thu Jun 1 18:16:11 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 1 Jun 2023 18:16:11 GMT Subject: RFR: 8304885: Reuse stale data to improve DNS resolver resiliency [v12] In-Reply-To: References:

Message-ID: On Tue, 30 May 2023 16:00:28 GMT, Sergey Bylokhov wrote: >> Sergey Bylokhov has updated the pull request incrementally with two additional commits since the last revision: >> >> - Apply suggestions from code review >> >> Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com> >> - Apply suggestions from code review >> >> Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com> > > patch and the CSR are updated as requested. @mrserb I'm seeing the new test failing intermittently on at least 3 different platforms when run in our CI. Here is a failure log example (this one is on macOS): ----------System.out:(1/84)---------- The following provider will be used by current test:impl.SimpleResolverProviderImpl ----------System.err:(22/1638)---------- Jun 01, 2023 2:37:32 PM testlib.ResolutionRegistry INFO: Creating ResolutionRegistry instance from file:/System/Volumes/Data/mesos/work_dir/jib-master/install/2023-06-01-1120469.daniel.fuchs.jdk-dev-git/src.full/open/test/jdk/java/net/spi/InetAddressResolverProvider/addresses.txt Jun 01, 2023 2:37:32 PM testlib.ResolutionRegistry parseDataFile INFO: Constructed addresses registry: javaTest.org: /1.2.3.4 /ca:fe:ba:be:0:0:0:1 Jun 01, 2023 2:37:32 PM impl.SimpleResolverProviderImpl$1 lookupByName INFO: Looking-up addresses for 'javaTest.org'. Lookup characteristics:111 Jun 01, 2023 2:37:32 PM testlib.ResolutionRegistry lookupHost INFO: Looking-up 'javaTest.org' address Jun 01, 2023 2:37:37 PM impl.SimpleResolverProviderImpl$1 lookupByName INFO: Looking-up addresses for 'javaTest.org'. Lookup characteristics:111 java.lang.AssertionError: Only one positive lookup is expected with caching enabled expected [1051960105228] but found [1046805905970] at org.testng.Assert.fail(Assert.java:99) at org.testng.Assert.failNotEquals(Assert.java:1037) at org.testng.Assert.assertEqualsImpl(Assert.java:140) at org.testng.Assert.assertEquals(Assert.java:122) at org.testng.Assert.assertEquals(Assert.java:797) at AddressesStaleCachingTest.doLookup(AddressesStaleCachingTest.java:137) at AddressesStaleCachingTest.lambda$testOnlyOneThreadIsBlockedDuringRefresh$0(AddressesStaleCachingTest.java:108) at java.base/java.lang.Thread.run(Thread.java:1583) STATUS:Failed.`main' threw exception: java.lang.AssertionError: Only one positive lookup is expected with caching enabled expected [1051960105228] but found [1046805905970] ------------- PR Comment: https://git.openjdk.org/jdk/pull/13285#issuecomment-1572559591 From serb at openjdk.org Thu Jun 1 18:41:09 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 1 Jun 2023 18:41:09 GMT Subject: RFR: 8304885: Reuse stale data to improve DNS resolver resiliency [v12] In-Reply-To: References:

Message-ID: On Mon, 29 May 2023 16:05:08 GMT, Sergey Bylokhov wrote: >> I would like to get preliminary feedback about the provided patch. >> >> Discussion on net-dev@ https://mail.openjdk.org/pipermail/net-dev/2023-March/020682.html >> >> One of the main issue I try to solve is how the cache handle the intermittent DNS server outages due to overloading or network connection. >> >> At the moment this cache can be configured by the application using the following two properties: >> (1) "networkaddress.cache.ttl"(30 sec) - cache policy for successful lookups >> (2) "networkaddress.cache.negative.ttl"(10 sec) - cache policy for negative lookups >> >> The default timeout for positive responses is good enough to "have recent dns-records" and to "minimize the number of requests to the DNS server". >> >> But the cache for the negative responses is problematic. This is a problem I would like to solve. Caching the negative response means that for **10** seconds the application will not be able to connect to the server. >> >> Possible solutions: >> 1. Decreasing timeout "for the negative responses": unfortunately more requests to the server at the moment of "DNS-outage" cause even more issues, since this is not the right moment to load the network/server more. >> 2. Increasing timeout "for the positive responses": this will decrease the chance to get an error, but the cache will start to use stale data longer. >> 3. This proposal: it would be good to ignore the negative response and continue to use the result of the last "successful lookup" until some additional timeout. >> >> The idea is to split the notion of the TTL and the timeout used for the cache. When TTL for the record will expire we should request the new data from the server. If this request goes fine we will update the record, if it fails we will continue to use the cached date until the next sync. >> >> For example, if the new property "networkaddress.cache.extended.ttl" is set to 10 minutes, then we will cache a positive response for 10 minutes but will try to sync it every 30 seconds. If the new property is not set then as before we will cache positive for 30 seconds and then cache the negative response for 10 seconds. >> >> >> RFC 8767 Serving Stale Data to Improve DNS Resiliency: >> https://www.rfc-editor.org/rfc/rfc8767 >> >> Comments about current and other possible implementations: >> * The code intentionally moved to the separate ValidAddresses class, just to make clear that the default configuration, when the new property is not set is not changed much. >> * The refr... > > Sergey Bylokhov has updated the pull request incrementally with two additional commits since the last revision: > > - Apply suggestions from code review > > Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com> > - Apply suggestions from code review > > Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com> The test expected to be completed in 2 seconds(10 lookups on a different threads). probably it is too short for mach5, will increase the time window. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13285#issuecomment-1572608619 From serb at openjdk.org Thu Jun 1 20:06:45 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 1 Jun 2023 20:06:45 GMT Subject: RFR: 8304885: Reuse stale data to improve DNS resolver resiliency [v13] In-Reply-To: References: Message-ID: <9SolZtNWEZUroBkwdGrRRitbOhpWNdHs-xywZiZXZ50=.0898395b-5ba0-407d-a9fb-48ca94eb72d9@github.com> > I would like to get preliminary feedback about the provided patch. > > Discussion on net-dev@ https://mail.openjdk.org/pipermail/net-dev/2023-March/020682.html > > One of the main issue I try to solve is how the cache handle the intermittent DNS server outages due to overloading or network connection. > > At the moment this cache can be configured by the application using the following two properties: > (1) "networkaddress.cache.ttl"(30 sec) - cache policy for successful lookups > (2) "networkaddress.cache.negative.ttl"(10 sec) - cache policy for negative lookups > > The default timeout for positive responses is good enough to "have recent dns-records" and to "minimize the number of requests to the DNS server". > > But the cache for the negative responses is problematic. This is a problem I would like to solve. Caching the negative response means that for **10** seconds the application will not be able to connect to the server. > > Possible solutions: > 1. Decreasing timeout "for the negative responses": unfortunately more requests to the server at the moment of "DNS-outage" cause even more issues, since this is not the right moment to load the network/server more. > 2. Increasing timeout "for the positive responses": this will decrease the chance to get an error, but the cache will start to use stale data longer. > 3. This proposal: it would be good to ignore the negative response and continue to use the result of the last "successful lookup" until some additional timeout. > > The idea is to split the notion of the TTL and the timeout used for the cache. When TTL for the record will expire we should request the new data from the server. If this request goes fine we will update the record, if it fails we will continue to use the cached date until the next sync. > > For example, if the new property "networkaddress.cache.extended.ttl" is set to 10 minutes, then we will cache a positive response for 10 minutes but will try to sync it every 30 seconds. If the new property is not set then as before we will cache positive for 30 seconds and then cache the negative response for 10 seconds. > > > RFC 8767 Serving Stale Data to Improve DNS Resiliency: > https://www.rfc-editor.org/rfc/rfc8767 > > Comments about current and other possible implementations: > * The code intentionally moved to the separate ValidAddresses class, just to make clear that the default configuration, when the new property is not set is not changed much. > * The refresh timeout includes the time s... Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision: Update the AddressesStaleCachingTest, make it ready for slow systems ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13285/files - new: https://git.openjdk.org/jdk/pull/13285/files/e0de2e0d..94c9f319 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13285&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13285&range=11-12 Stats: 13 lines in 2 files changed: 3 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/13285.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13285/head:pull/13285 PR: https://git.openjdk.org/jdk/pull/13285 From serb at openjdk.org Thu Jun 1 20:10:17 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 1 Jun 2023 20:10:17 GMT Subject: RFR: 8304885: Reuse stale data to improve DNS resolver resiliency [v13] In-Reply-To: <9SolZtNWEZUroBkwdGrRRitbOhpWNdHs-xywZiZXZ50=.0898395b-5ba0-407d-a9fb-48ca94eb72d9@github.com> References: <9SolZtNWEZUroBkwdGrRRitbOhpWNdHs-xywZiZXZ50=.0898395b-5ba0-407d-a9fb-48ca94eb72d9@github.com> Message-ID: On Thu, 1 Jun 2023 20:06:45 GMT, Sergey Bylokhov wrote: >> I would like to get preliminary feedback about the provided patch. >> >> Discussion on net-dev@ https://mail.openjdk.org/pipermail/net-dev/2023-March/020682.html >> >> One of the main issue I try to solve is how the cache handle the intermittent DNS server outages due to overloading or network connection. >> >> At the moment this cache can be configured by the application using the following two properties: >> (1) "networkaddress.cache.ttl"(30 sec) - cache policy for successful lookups >> (2) "networkaddress.cache.negative.ttl"(10 sec) - cache policy for negative lookups >> >> The default timeout for positive responses is good enough to "have recent dns-records" and to "minimize the number of requests to the DNS server". >> >> But the cache for the negative responses is problematic. This is a problem I would like to solve. Caching the negative response means that for **10** seconds the application will not be able to connect to the server. >> >> Possible solutions: >> 1. Decreasing timeout "for the negative responses": unfortunately more requests to the server at the moment of "DNS-outage" cause even more issues, since this is not the right moment to load the network/server more. >> 2. Increasing timeout "for the positive responses": this will decrease the chance to get an error, but the cache will start to use stale data longer. >> 3. This proposal: it would be good to ignore the negative response and continue to use the result of the last "successful lookup" until some additional timeout. >> >> The idea is to split the notion of the TTL and the timeout used for the cache. When TTL for the record will expire we should request the new data from the server. If this request goes fine we will update the record, if it fails we will continue to use the cached date until the next sync. >> >> For example, if the new property "networkaddress.cache.extended.ttl" is set to 10 minutes, then we will cache a positive response for 10 minutes but will try to sync it every 30 seconds. If the new property is not set then as before we will cache positive for 30 seconds and then cache the negative response for 10 seconds. >> >> >> RFC 8767 Serving Stale Data to Improve DNS Resiliency: >> https://www.rfc-editor.org/rfc/rfc8767 >> >> Comments about current and other possible implementations: >> * The code intentionally moved to the separate ValidAddresses class, just to make clear that the default configuration, when the new property is not set is not changed much. >> * The refr... > > Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision: > > Update the AddressesStaleCachingTest, make it ready for slow systems The test was expected to use two "refresh" time frames, in the first frame the dns record is cached, in the second frame the dns record should be updated by one thread only, all others should use the stale data. Initially the time-frame was equal to 2 seconds, now it is increased to 7 seconds. But even if the system is too slow the test now will ignore timestamp checks outside of 12 seconds which is less than 14 second(two frames). ------------- PR Comment: https://git.openjdk.org/jdk/pull/13285#issuecomment-1572704211 From serb at openjdk.org Thu Jun 1 20:16:39 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 1 Jun 2023 20:16:39 GMT Subject: RFR: 8304885: Reuse stale data to improve DNS resolver resiliency [v14] In-Reply-To: References: Message-ID: > I would like to get preliminary feedback about the provided patch. > > Discussion on net-dev@ https://mail.openjdk.org/pipermail/net-dev/2023-March/020682.html > > One of the main issue I try to solve is how the cache handle the intermittent DNS server outages due to overloading or network connection. > > At the moment this cache can be configured by the application using the following two properties: > (1) "networkaddress.cache.ttl"(30 sec) - cache policy for successful lookups > (2) "networkaddress.cache.negative.ttl"(10 sec) - cache policy for negative lookups > > The default timeout for positive responses is good enough to "have recent dns-records" and to "minimize the number of requests to the DNS server". > > But the cache for the negative responses is problematic. This is a problem I would like to solve. Caching the negative response means that for **10** seconds the application will not be able to connect to the server. > > Possible solutions: > 1. Decreasing timeout "for the negative responses": unfortunately more requests to the server at the moment of "DNS-outage" cause even more issues, since this is not the right moment to load the network/server more. > 2. Increasing timeout "for the positive responses": this will decrease the chance to get an error, but the cache will start to use stale data longer. > 3. This proposal: it would be good to ignore the negative response and continue to use the result of the last "successful lookup" until some additional timeout. > > The idea is to split the notion of the TTL and the timeout used for the cache. When TTL for the record will expire we should request the new data from the server. If this request goes fine we will update the record, if it fails we will continue to use the cached date until the next sync. > > For example, if the new property "networkaddress.cache.extended.ttl" is set to 10 minutes, then we will cache a positive response for 10 minutes but will try to sync it every 30 seconds. If the new property is not set then as before we will cache positive for 30 seconds and then cache the negative response for 10 seconds. > > > RFC 8767 Serving Stale Data to Improve DNS Resiliency: > https://www.rfc-editor.org/rfc/rfc8767 > > Comments about current and other possible implementations: > * The code intentionally moved to the separate ValidAddresses class, just to make clear that the default configuration, when the new property is not set is not changed much. > * The refresh timeout includes the time s... Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision: Update AddressesStaleCachingTest.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13285/files - new: https://git.openjdk.org/jdk/pull/13285/files/94c9f319..3ab77529 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13285&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13285&range=12-13 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13285.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13285/head:pull/13285 PR: https://git.openjdk.org/jdk/pull/13285 From serb at openjdk.org Thu Jun 1 20:45:10 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 1 Jun 2023 20:45:10 GMT Subject: RFR: 8304885: Reuse stale data to improve DNS resolver resiliency [v14] In-Reply-To: References:

Message-ID: On Thu, 1 Jun 2023 20:16:39 GMT, Sergey Bylokhov wrote: >> I would like to get preliminary feedback about the provided patch. >> >> Discussion on net-dev@ https://mail.openjdk.org/pipermail/net-dev/2023-March/020682.html >> >> One of the main issue I try to solve is how the cache handle the intermittent DNS server outages due to overloading or network connection. >> >> At the moment this cache can be configured by the application using the following two properties: >> (1) "networkaddress.cache.ttl"(30 sec) - cache policy for successful lookups >> (2) "networkaddress.cache.negative.ttl"(10 sec) - cache policy for negative lookups >> >> The default timeout for positive responses is good enough to "have recent dns-records" and to "minimize the number of requests to the DNS server". >> >> But the cache for the negative responses is problematic. This is a problem I would like to solve. Caching the negative response means that for **10** seconds the application will not be able to connect to the server. >> >> Possible solutions: >> 1. Decreasing timeout "for the negative responses": unfortunately more requests to the server at the moment of "DNS-outage" cause even more issues, since this is not the right moment to load the network/server more. >> 2. Increasing timeout "for the positive responses": this will decrease the chance to get an error, but the cache will start to use stale data longer. >> 3. This proposal: it would be good to ignore the negative response and continue to use the result of the last "successful lookup" until some additional timeout. >> >> The idea is to split the notion of the TTL and the timeout used for the cache. When TTL for the record will expire we should request the new data from the server. If this request goes fine we will update the record, if it fails we will continue to use the cached date until the next sync. >> >> For example, if the new property "networkaddress.cache.extended.ttl" is set to 10 minutes, then we will cache a positive response for 10 minutes but will try to sync it every 30 seconds. If the new property is not set then as before we will cache positive for 30 seconds and then cache the negative response for 10 seconds. >> >> >> RFC 8767 Serving Stale Data to Improve DNS Resiliency: >> https://www.rfc-editor.org/rfc/rfc8767 >> >> Comments about current and other possible implementations: >> * The code intentionally moved to the separate ValidAddresses class, just to make clear that the default configuration, when the new property is not set is not changed much. >> * The refr... > > Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision: > > Update AddressesStaleCachingTest.java Another possible problem is that the Thread.sleep used by the test may not be accurate enough, I will change that as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13285#issuecomment-1572750723 From serb at openjdk.org Thu Jun 1 21:28:23 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 1 Jun 2023 21:28:23 GMT Subject: RFR: 8304885: Reuse stale data to improve DNS resolver resiliency [v15] In-Reply-To: References: Message-ID: > I would like to get preliminary feedback about the provided patch. > > Discussion on net-dev@ https://mail.openjdk.org/pipermail/net-dev/2023-March/020682.html > > One of the main issue I try to solve is how the cache handle the intermittent DNS server outages due to overloading or network connection. > > At the moment this cache can be configured by the application using the following two properties: > (1) "networkaddress.cache.ttl"(30 sec) - cache policy for successful lookups > (2) "networkaddress.cache.negative.ttl"(10 sec) - cache policy for negative lookups > > The default timeout for positive responses is good enough to "have recent dns-records" and to "minimize the number of requests to the DNS server". > > But the cache for the negative responses is problematic. This is a problem I would like to solve. Caching the negative response means that for **10** seconds the application will not be able to connect to the server. > > Possible solutions: > 1. Decreasing timeout "for the negative responses": unfortunately more requests to the server at the moment of "DNS-outage" cause even more issues, since this is not the right moment to load the network/server more. > 2. Increasing timeout "for the positive responses": this will decrease the chance to get an error, but the cache will start to use stale data longer. > 3. This proposal: it would be good to ignore the negative response and continue to use the result of the last "successful lookup" until some additional timeout. > > The idea is to split the notion of the TTL and the timeout used for the cache. When TTL for the record will expire we should request the new data from the server. If this request goes fine we will update the record, if it fails we will continue to use the cached date until the next sync. > > For example, if the new property "networkaddress.cache.extended.ttl" is set to 10 minutes, then we will cache a positive response for 10 minutes but will try to sync it every 30 seconds. If the new property is not set then as before we will cache positive for 30 seconds and then cache the negative response for 10 seconds. > > > RFC 8767 Serving Stale Data to Improve DNS Resiliency: > https://www.rfc-editor.org/rfc/rfc8767 > > Comments about current and other possible implementations: > * The code intentionally moved to the separate ValidAddresses class, just to make clear that the default configuration, when the new property is not set is not changed much. > * The refresh timeout includes the time s... Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision: Fix possible race in the SimpleResolverProviderImpl ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13285/files - new: https://git.openjdk.org/jdk/pull/13285/files/3ab77529..7bb0de6f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13285&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13285&range=13-14 Stats: 10 lines in 1 file changed: 5 ins; 5 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13285.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13285/head:pull/13285 PR: https://git.openjdk.org/jdk/pull/13285 From serb at openjdk.org Thu Jun 1 21:46:14 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 1 Jun 2023 21:46:14 GMT Subject: RFR: 8304885: Reuse stale data to improve DNS resolver resiliency [v12] In-Reply-To: References:

Message-ID: On Thu, 1 Jun 2023 18:13:37 GMT, Daniel Fuchs wrote: >> patch and the CSR are updated as requested. > > @mrserb I'm seeing the new test failing intermittently on at least 3 different platforms when run in our CI. > > Here is a failure log example (this one is on macOS): > > > ----------System.out:(1/84)---------- > The following provider will be used by current test:impl.SimpleResolverProviderImpl > ----------System.err:(22/1638)---------- > Jun 01, 2023 2:37:32 PM testlib.ResolutionRegistry > INFO: Creating ResolutionRegistry instance from file:/.../open/test/jdk/java/net/spi/InetAddressResolverProvider/addresses.txt > Jun 01, 2023 2:37:32 PM testlib.ResolutionRegistry parseDataFile > INFO: Constructed addresses registry: > javaTest.org: /1.2.3.4 /ca:fe:ba:be:0:0:0:1 > > Jun 01, 2023 2:37:32 PM impl.SimpleResolverProviderImpl$1 lookupByName > INFO: Looking-up addresses for 'javaTest.org'. Lookup characteristics:111 > Jun 01, 2023 2:37:32 PM testlib.ResolutionRegistry lookupHost > INFO: Looking-up 'javaTest.org' address > Jun 01, 2023 2:37:37 PM impl.SimpleResolverProviderImpl$1 lookupByName > INFO: Looking-up addresses for 'javaTest.org'. Lookup characteristics:111 > java.lang.AssertionError: Only one positive lookup is expected with caching enabled expected [1051960105228] but found [1046805905970] > at org.testng.Assert.fail(Assert.java:99) > at org.testng.Assert.failNotEquals(Assert.java:1037) > at org.testng.Assert.assertEqualsImpl(Assert.java:140) > at org.testng.Assert.assertEquals(Assert.java:122) > at org.testng.Assert.assertEquals(Assert.java:797) > at AddressesStaleCachingTest.doLookup(AddressesStaleCachingTest.java:137) > at AddressesStaleCachingTest.lambda$testOnlyOneThreadIsBlockedDuringRefresh$0(AddressesStaleCachingTest.java:108) > at java.base/java.lang.Thread.run(Thread.java:1583) > STATUS:Failed.`main' threw exception: java.lang.AssertionError: Only one positive lookup is expected with caching enabled expected [1051960105228] but found [1046805905970] @dfuch the test is updated, please take a look, it includes: - The fix for the slow systems when it was not enough time to complete the test. - The fix for the possible race in the SimpleResolverProviderImpl: 1 Thread_1 decided to refresh the record, it takes the lock in the InetAddress.java, but do not call the ResolverProvider yet. 2 Thread_2 decided to get a lock, fail to do that, take a stale data, and save the timestamp 3 Thread_1 call the ResolverProvider and update the timestamp, then intentionally hangs(becouse of the blocker) 4 Thread_2 decided to get a lock, fail to do that again, take a stale data, and save the timestamp 5 Thread_2 fails to compare timestamps from steps 2 and 4 It was fixed in the SimpleResolverProviderImpl, the blocked thread should update the timestamps at the end. Note that I was not able to reproduce the problems above out of the box, but was able to do that by adding some custom delays here and there in the JDK code. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13285#issuecomment-1572828425 From mbaesken at openjdk.org Fri Jun 2 08:09:32 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 2 Jun 2023 08:09:32 GMT Subject: RFR: JDK-8309340: Provide sctpHandleSocketErrorWithMessage Message-ID: There are cases in the sctp coding where a function sctpHandleSocketErrorWithMessage would be beneficial (similar to existing handleSocketErrorWithMessage) to provide more detail what failed. Additionally sctpHandleSocketErrorWithMessage was a bit modified (added errno handling for ENOTCONN from handleSocketErrorWithMessage). ------------- Commit messages: - JDK-8309340 Changes: https://git.openjdk.org/jdk/pull/14280/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14280&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8309340 Stats: 20 lines in 2 files changed: 11 ins; 2 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/14280.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14280/head:pull/14280 PR: https://git.openjdk.org/jdk/pull/14280 From jpai at openjdk.org Fri Jun 2 08:31:10 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 2 Jun 2023 08:31:10 GMT Subject: RFR: 8309200: java/net/httpclient/ExecutorShutdown fais intermittently, if connection closed during upgrade [v2] In-Reply-To: References:

Message-ID: <3JQrq6EnHA-Zct0y6ZNx1rC7IreyRsaiA01MgUcEGY8=.2e5c0ffd-c42e-4998-a5ef-01524adf74c4@github.com> On Thu, 1 Jun 2023 11:09:37 GMT, Daniel Fuchs wrote: >> The ExecutorShutdown test has been observed failing intermittently, notably if by misfortune the shutdown sequence causes a connection to get aborted while upgrading. The issue is that the `ConnectionAborter` class that allows to mark the connection as being scheduled for closing before a handle to the connection is actually available isn't forwarding the original exception for which closing the connection was requested. When the connection is eventually closed, a generic `IOException: connection closed locally` is raised at the `SocketTube` level, which unfortunately can race with the original cause. >> >> The fix makes it possible to relay the original cause to the place where the IOException is raised, in order to set it as the cause of the new exception. > > Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision: > > Review feedback The changes look fine to me. I have a minor comment about the code in the ConnectionAborter, which I've added inline. It's OK with me if you prefer to maintain it in its current form in the PR. src/java.net.http/share/classes/jdk/internal/net/http/Exchange.java line 176: > 174: } else { > 175: this.connection = null; > 176: this.cause = null; Hello Daniel, I had to read this a few times to understand why we are resetting `this.cause`, which we potentially set a few lines above, to `null` here. From what I understand, we only want to set `this.cause` when the `connection` is `null`. Do you think this code could instead of written as: Throwable cause; synchronized (this) { cause = this.cause; if (cause == null) { cause = error; } connection = this.connection; if (connection == null) { closeRequested = true; this.cause = cause; } else { this.connection = null; this.cause = null; } } ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14251#pullrequestreview-1456894820 PR Review Comment: https://git.openjdk.org/jdk/pull/14251#discussion_r1214079485 From djelinski at openjdk.org Fri Jun 2 09:30:06 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 2 Jun 2023 09:30:06 GMT Subject: RFR: 8309200: java/net/httpclient/ExecutorShutdown fais intermittently, if connection closed during upgrade [v2] In-Reply-To: References:

Message-ID: <_zul0dvx37mhxpSuDKJSeDm6kEq5lt1ePW4HK57gvQ0=.6a173b29-a4c4-4405-9d86-7ebc70d1d067@github.com> On Thu, 1 Jun 2023 11:09:37 GMT, Daniel Fuchs wrote: >> The ExecutorShutdown test has been observed failing intermittently, notably if by misfortune the shutdown sequence causes a connection to get aborted while upgrading. The issue is that the `ConnectionAborter` class that allows to mark the connection as being scheduled for closing before a handle to the connection is actually available isn't forwarding the original exception for which closing the connection was requested. When the connection is eventually closed, a generic `IOException: connection closed locally` is raised at the `SocketTube` level, which unfortunately can race with the original cause. >> >> The fix makes it possible to relay the original cause to the place where the IOException is raised, in order to set it as the cause of the new exception. > > Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision: > > Review feedback Marked as reviewed by djelinski (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14251#pullrequestreview-1456989514 From dfuchs at openjdk.org Fri Jun 2 10:44:06 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 2 Jun 2023 10:44:06 GMT Subject: RFR: 8309200: java/net/httpclient/ExecutorShutdown fails intermittently, if connection closed during upgrade [v2] In-Reply-To: <3JQrq6EnHA-Zct0y6ZNx1rC7IreyRsaiA01MgUcEGY8=.2e5c0ffd-c42e-4998-a5ef-01524adf74c4@github.com> References:

<3JQrq6EnHA-Zct0y6ZNx1rC7IreyRsaiA01MgUcEGY8=.2e5c0ffd-c42e-4998-a5ef-01524adf74c4@github.com> Message-ID: On Fri, 2 Jun 2023 08:25:35 GMT, Jaikiran Pai wrote: >> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision: >> >> Review feedback > > src/java.net.http/share/classes/jdk/internal/net/http/Exchange.java line 176: > >> 174: } else { >> 175: this.connection = null; >> 176: this.cause = null; > > Hello Daniel, I had to read this a few times to understand why we are resetting `this.cause`, which we potentially set a few lines above, to `null` here. From what I understand, we only want to set `this.cause` when the `connection` is `null`. Do you think this code could instead of written as: > > > Throwable cause; > synchronized (this) { > cause = this.cause; > if (cause == null) { > cause = error; > } > connection = this.connection; > if (connection == null) { > closeRequested = true; > this.cause = cause; > } else { > this.connection = null; > this.cause = null; > } > } Much better yes. I'll steal it! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14251#discussion_r1214212516 From dfuchs at openjdk.org Fri Jun 2 10:51:24 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 2 Jun 2023 10:51:24 GMT Subject: RFR: 8309200: java/net/httpclient/ExecutorShutdown fails intermittently, if connection closed during upgrade [v3] In-Reply-To: References: Message-ID: > The ExecutorShutdown test has been observed failing intermittently, notably if by misfortune the shutdown sequence causes a connection to get aborted while upgrading. The issue is that the `ConnectionAborter` class that allows to mark the connection as being scheduled for closing before a handle to the connection is actually available isn't forwarding the original exception for which closing the connection was requested. When the connection is eventually closed, a generic `IOException: connection closed locally` is raised at the `SocketTube` level, which unfortunately can race with the original cause. > > The fix makes it possible to relay the original cause to the place where the IOException is raised, in order to set it as the cause of the new exception. Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision: More review feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14251/files - new: https://git.openjdk.org/jdk/pull/14251/files/5fb0731e..3d3597ae Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14251&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14251&range=01-02 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14251.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14251/head:pull/14251 PR: https://git.openjdk.org/jdk/pull/14251 From jpai at openjdk.org Fri Jun 2 10:59:05 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 2 Jun 2023 10:59:05 GMT Subject: RFR: 8309200: java/net/httpclient/ExecutorShutdown fails intermittently, if connection closed during upgrade [v3] In-Reply-To: References:

Message-ID: <-7mvuio_pkzNl-CVy6rMLPJN8Oj80Q0KTRV1zetGWWM=.7f7724b3-4624-4b80-885f-57ad67ca84b6@github.com> On Fri, 2 Jun 2023 10:51:24 GMT, Daniel Fuchs wrote: >> The ExecutorShutdown test has been observed failing intermittently, notably if by misfortune the shutdown sequence causes a connection to get aborted while upgrading. The issue is that the `ConnectionAborter` class that allows to mark the connection as being scheduled for closing before a handle to the connection is actually available isn't forwarding the original exception for which closing the connection was requested. When the connection is eventually closed, a generic `IOException: connection closed locally` is raised at the `SocketTube` level, which unfortunately can race with the original cause. >> >> The fix makes it possible to relay the original cause to the place where the IOException is raised, in order to set it as the cause of the new exception. > > Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision: > > More review feedback Thank you Daniel for the update. Looks good to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14251#pullrequestreview-1457120562 From dfuchs at openjdk.org Fri Jun 2 14:38:15 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 2 Jun 2023 14:38:15 GMT Subject: Integrated: 8309200: java/net/httpclient/ExecutorShutdown fails intermittently, if connection closed during upgrade In-Reply-To: References: Message-ID: On Wed, 31 May 2023 16:52:02 GMT, Daniel Fuchs wrote: > The ExecutorShutdown test has been observed failing intermittently, notably if by misfortune the shutdown sequence causes a connection to get aborted while upgrading. The issue is that the `ConnectionAborter` class that allows to mark the connection as being scheduled for closing before a handle to the connection is actually available isn't forwarding the original exception for which closing the connection was requested. When the connection is eventually closed, a generic `IOException: connection closed locally` is raised at the `SocketTube` level, which unfortunately can race with the original cause. > > The fix makes it possible to relay the original cause to the place where the IOException is raised, in order to set it as the cause of the new exception. This pull request has now been integrated. Changeset: 931913fb Author: Daniel Fuchs URL: https://git.openjdk.org/jdk/commit/931913fbb299fbed7485ab8229100e6e56d8bada Stats: 63 lines in 7 files changed: 45 ins; 3 del; 15 mod 8309200: java/net/httpclient/ExecutorShutdown fails intermittently, if connection closed during upgrade Reviewed-by: jpai, djelinski ------------- PR: https://git.openjdk.org/jdk/pull/14251 From dfuchs at openjdk.org Fri Jun 2 17:06:12 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 2 Jun 2023 17:06:12 GMT Subject: RFR: 8304885: Reuse stale data to improve DNS resolver resiliency [v15] In-Reply-To: References:

Message-ID: <7nABYFg2WeolHZuAWt05pTTbnsZqa1UrpaaTxvQUi_s=.ea06c2f0-9d7f-46cd-b6af-f75b537494d3@github.com> On Thu, 1 Jun 2023 21:28:23 GMT, Sergey Bylokhov wrote: >> I would like to get preliminary feedback about the provided patch. >> >> Discussion on net-dev@ https://mail.openjdk.org/pipermail/net-dev/2023-March/020682.html >> >> One of the main issue I try to solve is how the cache handle the intermittent DNS server outages due to overloading or network connection. >> >> At the moment this cache can be configured by the application using the following two properties: >> (1) "networkaddress.cache.ttl"(30 sec) - cache policy for successful lookups >> (2) "networkaddress.cache.negative.ttl"(10 sec) - cache policy for negative lookups >> >> The default timeout for positive responses is good enough to "have recent dns-records" and to "minimize the number of requests to the DNS server". >> >> But the cache for the negative responses is problematic. This is a problem I would like to solve. Caching the negative response means that for **10** seconds the application will not be able to connect to the server. >> >> Possible solutions: >> 1. Decreasing timeout "for the negative responses": unfortunately more requests to the server at the moment of "DNS-outage" cause even more issues, since this is not the right moment to load the network/server more. >> 2. Increasing timeout "for the positive responses": this will decrease the chance to get an error, but the cache will start to use stale data longer. >> 3. This proposal: it would be good to ignore the negative response and continue to use the result of the last "successful lookup" until some additional timeout. >> >> The idea is to split the notion of the TTL and the timeout used for the cache. When TTL for the record will expire we should request the new data from the server. If this request goes fine we will update the record, if it fails we will continue to use the cached date until the next sync. >> >> For example, if the new property "networkaddress.cache.extended.ttl" is set to 10 minutes, then we will cache a positive response for 10 minutes but will try to sync it every 30 seconds. If the new property is not set then as before we will cache positive for 30 seconds and then cache the negative response for 10 seconds. >> >> >> RFC 8767 Serving Stale Data to Improve DNS Resiliency: >> https://www.rfc-editor.org/rfc/rfc8767 >> >> Comments about current and other possible implementations: >> * The code intentionally moved to the separate ValidAddresses class, just to make clear that the default configuration, when the new property is not set is not changed much. >> * The refr... > > Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision: > > Fix possible race in the SimpleResolverProviderImpl Thanks - with the latest changes the test appears to be stable. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13285#issuecomment-1574048850 From v-terrychow at microsoft.com Fri Jun 2 20:56:06 2023 From: v-terrychow at microsoft.com (Terry Chow (Simba Technologies Inc)) Date: Fri, 2 Jun 2023 20:56:06 +0000 Subject: Support for Keepalive Extended Socket Options On Windows Message-ID: Hi all, I'm Terry and I'm from the mssql-jdbc driver team. I'd like to propose some changes to JDK that would allow for keepalive extended socket options support for Windows in order maintain feature parity within the mssql-jdbc driver project. Currently, keepalive options are only supported on Linux and Mac. I did some research on this and there are some points to consider when implementing this change. On Windows, to set the keepalive values, we do so natively through the SIO_KEEPALIVE_VALS control code. The problem however is that the API requires that keepalive time and interval be configured at the same time. So, the semantics of SIO_KEEPALIVE_VALS are the same as TCP_KEEPIDLE + TCP_KEEPINTERVAL on other platforms -- setting keepalive values through SIO_KEEPALIVE_VALS is the same as setting it through TCP_KEEPIDLE + TCP_KEEPINTERVAL at once for other platforms. Another issue is that it's not possible to query the current keepalive values. However, there are system-wide default keepalive values. For keepalive time and interval on Windows, they're officially 2hrs and 1s respectively. But, it's possible these default values could be different. A possible idea I had was to introduce a new setOption that would set both keepalive values at the same time and reuse existing options in the JDK. So, something like below would be valid across all platforms. eg. socket.setOption(ExtendedSocketOptions.TCP_KEEPIDLE, 30, ExtendedSocketOptions.TCP_KEEPINTERVAL, 30); Another idea was to introduce a new Windows and JDK specific socket option. Earlier in the week I prematurely submitted a PR for this, apologies for that (I went through my org in order to submit a PR and thought dialog for something like this happens after). Relevant links: https://bugs.openjdk.org/browse/JDK-8308593 https://learn.microsoft.com/en-us/windows/win32/winsock/sio-keepalive-vals https://learn.microsoft.com/en-us/windows/win32/winsock/sio-keepalive-vals#remarks https://stackoverflow.com/questions/14197347/how-to-query-socket-keep-alive-values-using-winsock/14198462#14198462 https://stackoverflow.com/questions/18391341/reading-sio-keepalive-vals-fields-on-a-windows-socket-for-keepalive-idle-and-in Any feedback and guidance on how this should be approached is appreciated. Thanks, Terry -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Sat Jun 3 07:19:10 2023 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 3 Jun 2023 08:19:10 +0100 Subject: Support for Keepalive Extended Socket Options On Windows In-Reply-To: References: Message-ID: <185edc7f-437d-5a75-35ef-6e39a38c9210@oracle.com> On 02/06/2023 21:56, Terry Chow (Simba Technologies Inc) wrote: > Hi all, > > I'm Terry and I'm from the mssql-jdbc driver team. I'd like to propose > some changes to JDK that would allow for keepalive extended socket > options support for Windows in order maintain feature parity within > the mssql-jdbc driver project. Currently, keepalive options are only > supported on Linux and Mac. > Just curious if your team has lobbied the Windows folks to provide the equivalent of? the TCP_KEEPIDLE and TCP_KEEPINTERVAL options so they work like other platforms? There is exploration in PR14232 on implementation these socket options with SIO_KEEPALIVE_VALS but it will require disruptive changes in order to make them to existing APIs. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpai at openjdk.org Sun Jun 4 09:40:25 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Sun, 4 Jun 2023 09:40:25 GMT Subject: RFR: 8309409: Update HttpInputStreamTest and BodyProcessorInputStreamTest to use hg.openjdk.org Message-ID: Can I please get a review of this test-only change which updates these manual tests to use `https://hg.openjdk.org` instead of `http://hg.openjdk.java.net`? I've run these manual tests locally and they now pass with this change. ------------- Commit messages: - 8309409: Update HttpInputStreamTest and BodyProcessorInputStreamTest to use hg.openjdk.org Changes: https://git.openjdk.org/jdk/pull/14302/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14302&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8309409 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/14302.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14302/head:pull/14302 PR: https://git.openjdk.org/jdk/pull/14302 From dfuchs at openjdk.org Sun Jun 4 09:44:04 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Sun, 4 Jun 2023 09:44:04 GMT Subject: RFR: 8309409: Update HttpInputStreamTest and BodyProcessorInputStreamTest to use hg.openjdk.org In-Reply-To: References: Message-ID: On Sun, 4 Jun 2023 09:33:43 GMT, Jaikiran Pai wrote: > Can I please get a review of this test-only change which updates these manual tests to use `https://hg.openjdk.org` instead of `http://hg.openjdk.java.net`? > > I've run these manual tests locally and they now pass with this change. Thanks for noticing that Jaikiran. LGTM! ------------- Marked as reviewed by dfuchs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14302#pullrequestreview-1461073358 From daniel.fuchs at oracle.com Sun Jun 4 09:49:21 2023 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Sun, 4 Jun 2023 10:49:21 +0100 Subject: Support for Keepalive Extended Socket Options On Windows In-Reply-To: <185edc7f-437d-5a75-35ef-6e39a38c9210@oracle.com> References: <185edc7f-437d-5a75-35ef-6e39a38c9210@oracle.com> Message-ID: <8e0c41f8-f4fa-334f-c5d3-3d42b84a21d0@oracle.com> Hi, Could we maybe cache the values in the SocketImpl/NIOSocketImpl implementation? IIRC we do something like that for SO_TIMEOUT already, since this is handled at NIO level. If we know the default value then setting one (when the other is not set) could set it with the supplied value for the one, and the default (or cached value) for the other? Get would then return the cached value (or possibly default value if not set?) We could also potentially set some sensible defaults when creating the socket. Just some ideas.. best regards, -- daniel On 03/06/2023 08:19, Alan Bateman wrote: > On 02/06/2023 21:56, Terry Chow (Simba Technologies Inc) wrote: >> Hi all, >> >> I'm Terry and I'm from the mssql-jdbc driver team. I'd like to propose >> some changes to JDK that would allow for keepalive extended socket >> options support for Windows in order maintain feature parity within >> the mssql-jdbc driver project. Currently, keepalive options are only >> supported on Linux and Mac. >> > Just curious if your team has lobbied the Windows folks to provide the > equivalent of? the TCP_KEEPIDLE and TCP_KEEPINTERVAL options so they > work like other platforms? > > There is exploration in PR14232 on implementation these socket options > with SIO_KEEPALIVE_VALS but it will require disruptive changes in order > to make them to existing APIs. > > -Alan From jpai at openjdk.org Sun Jun 4 09:52:11 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Sun, 4 Jun 2023 09:52:11 GMT Subject: RFR: 8309409: Update HttpInputStreamTest and BodyProcessorInputStreamTest to use hg.openjdk.org In-Reply-To: References: Message-ID: <7Sq1csWxO_SiBpopmy2_G8W_3dZbCzmKRpNLwUCElMI=.3ccd066b-52d8-4f26-914c-733720515596@github.com> On Sun, 4 Jun 2023 09:33:43 GMT, Jaikiran Pai wrote: > Can I please get a review of this test-only change which updates these manual tests to use `https://hg.openjdk.org` instead of `http://hg.openjdk.java.net`? > > I've run these manual tests locally and they now pass with this change. Thank you Daniel for the quick review. Given that these are manual tests that don't get run in the CI (or github actions) and now that they are passing locally, I'll go ahead and integrate this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14302#issuecomment-1575493076 From jpai at openjdk.org Sun Jun 4 09:52:12 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Sun, 4 Jun 2023 09:52:12 GMT Subject: Integrated: 8309409: Update HttpInputStreamTest and BodyProcessorInputStreamTest to use hg.openjdk.org In-Reply-To: References: Message-ID: On Sun, 4 Jun 2023 09:33:43 GMT, Jaikiran Pai wrote: > Can I please get a review of this test-only change which updates these manual tests to use `https://hg.openjdk.org` instead of `http://hg.openjdk.java.net`? > > I've run these manual tests locally and they now pass with this change. This pull request has now been integrated. Changeset: ac1597bc Author: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/ac1597bcc7a81db0b81e82a3faf50e73932764c2 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod 8309409: Update HttpInputStreamTest and BodyProcessorInputStreamTest to use hg.openjdk.org Reviewed-by: dfuchs ------------- PR: https://git.openjdk.org/jdk/pull/14302 From Alan.Bateman at oracle.com Sun Jun 4 14:32:16 2023 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 4 Jun 2023 15:32:16 +0100 Subject: Support for Keepalive Extended Socket Options On Windows In-Reply-To: <8e0c41f8-f4fa-334f-c5d3-3d42b84a21d0@oracle.com> References: <185edc7f-437d-5a75-35ef-6e39a38c9210@oracle.com> <8e0c41f8-f4fa-334f-c5d3-3d42b84a21d0@oracle.com> Message-ID: On 04/06/2023 10:49, Daniel Fuchs wrote: > Hi, > > Could we maybe cache the values in the SocketImpl/NIOSocketImpl > implementation? > > IIRC we do something like that for SO_TIMEOUT already, since this > is handled at NIO level. > > If we know the default value then setting one (when the other is > not set) could set it with the supplied value for the one, and > the default (or cached value) for the other? > > Get would then return the cached value (or possibly default > value if not set?) > > We could also potentially set some sensible defaults when creating > the socket. > Yes, this is what I was suggesting in PR14232 too but it will likely be a disruptive change. It can be prototyped at least, then we can see how we could turn it into something that is maintainable. The best outcome would of course be for Windows to expose the socket options in the same way as Linux, macOS and others. -Alan From clanger at openjdk.org Mon Jun 5 11:51:05 2023 From: clanger at openjdk.org (Christoph Langer) Date: Mon, 5 Jun 2023 11:51:05 GMT Subject: RFR: JDK-8309340: Provide sctpHandleSocketErrorWithMessage In-Reply-To: References: Message-ID: On Fri, 2 Jun 2023 08:03:01 GMT, Matthias Baesken wrote: > There are cases in the sctp coding where a function sctpHandleSocketErrorWithMessage would be beneficial (similar to existing handleSocketErrorWithMessage) to provide more detail what failed. > > Additionally sctpHandleSocketErrorWithMessage was a bit modified (added errno handling for ENOTCONN from handleSocketErrorWithMessage). LGTM ------------- Marked as reviewed by clanger (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14280#pullrequestreview-1462355243 From v-terrychow at microsoft.com Mon Jun 5 19:52:20 2023 From: v-terrychow at microsoft.com (Terry Chow (Simba Technologies Inc)) Date: Mon, 5 Jun 2023 19:52:20 +0000 Subject: [EXTERNAL] Re: Support for Keepalive Extended Socket Options On Windows In-Reply-To: References: <185edc7f-437d-5a75-35ef-6e39a38c9210@oracle.com> <8e0c41f8-f4fa-334f-c5d3-3d42b84a21d0@oracle.com> Message-ID: Hi Alan and Daniel, Agreed, having Windows support the keepalive options as it's done on other platforms would be the best. But, lobbying them for that change would be extremely difficult as it would be very significant change that impacts the whole platform. What defaults values do you guys have in mind? I'm still hesitating on persisting default values because the default values can vary between machines. Thanks, Terry ________________________________ From: Alan Bateman Sent: June 4, 2023 7:32 AM To: Daniel Fuchs ; Terry Chow (Simba Technologies Inc) ; net-dev at openjdk.org Subject: [EXTERNAL] Re: Support for Keepalive Extended Socket Options On Windows [You don't often get email from alan.bateman at oracle.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] On 04/06/2023 10:49, Daniel Fuchs wrote: > Hi, > > Could we maybe cache the values in the SocketImpl/NIOSocketImpl > implementation? > > IIRC we do something like that for SO_TIMEOUT already, since this > is handled at NIO level. > > If we know the default value then setting one (when the other is > not set) could set it with the supplied value for the one, and > the default (or cached value) for the other? > > Get would then return the cached value (or possibly default > value if not set?) > > We could also potentially set some sensible defaults when creating > the socket. > Yes, this is what I was suggesting in PR14232 too but it will likely be a disruptive change. It can be prototyped at least, then we can see how we could turn it into something that is maintainable. The best outcome would of course be for Windows to expose the socket options in the same way as Linux, macOS and others. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Tue Jun 6 06:06:51 2023 From: duke at openjdk.org (Deepa Kumari) Date: Tue, 6 Jun 2023 06:06:51 GMT Subject: RFR: 8308807: [AIX] MulticastSocket and jdp test fails due to joinGroup In-Reply-To: References: <4tkYKvpBoxO7IK4HevAqpEY5KoqxXUK6rs0scqyxgJc=.69de9b21-5a2f-45ef-b05f-1bc8ad398dad@github.com> Message-ID: On Thu, 25 May 2023 07:37:27 GMT, Alan Bateman wrote: >> DatagramSocket delegates to an inner DatagramSocket object. Irrespective of whether datagramSocket is IPv4 or IPv6, we create an IPv6 datagramChannel as its's delegate. So, This can cause problems with operations like joinGroup. >> >> On AIX, IPv6 datagramSocket can not join an IPv4 multicast group. >> >> These failures can be fixed by making sure that the delegate created for a datagram socket has the same protocol family. >> >> >> >> >> Reported Issue : [JDK-8308807](https://bugs.openjdk.org/browse/JDK-8308807) > > I've moved the JBS issue to the right place and fix the description. > > The changes proposed here impact all platforms and will require discussion and cleanup. If I understand the intent, if you create a DatagramSocket or MulticastSocket that is bound to a specific local address then you want to use that to determine if the underlying socket is IPv4 or IPv6. That might be okay but multicasting normally means binding to the wildcard address so it doesn't help - I assume it only works for the test because new InetSocketAddress(port).getAddress() returns an Inet4Address so you get an IPv4 socket. It should only create a dual IPv4/IPv6 socket for this case so this is why it will break other platforms. In any case, can you look at the isXXX methods defined by sun.nio.ch.Net to see how it is handled on other platforms. Yes, I agree with @AlanBateman and @msheppar . Even when we try to have an IPv4 multicast socket join an IPv4 multicast group, we still fail because the delegate that is created for an IPv4 multicast socket is IPv4/IPv6 (dual stack) in nature. AIX does not allow dual stack (IPv4/IPv6) sockets to join IPv4 multicast groups. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14142#issuecomment-1577968863 From mbaesken at openjdk.org Tue Jun 6 07:12:02 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 6 Jun 2023 07:12:02 GMT Subject: RFR: JDK-8309340: Provide sctpHandleSocketErrorWithMessage In-Reply-To: References: Message-ID: On Fri, 2 Jun 2023 08:03:01 GMT, Matthias Baesken wrote: > There are cases in the sctp coding where a function sctpHandleSocketErrorWithMessage would be beneficial (similar to existing handleSocketErrorWithMessage) to provide more detail what failed. > > Additionally sctpHandleSocketErrorWithMessage was a bit modified (added errno handling for ENOTCONN from handleSocketErrorWithMessage). Hi Christoph, thanks for the review ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/14280#issuecomment-1578046570 From mbaesken at openjdk.org Tue Jun 6 07:12:02 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 6 Jun 2023 07:12:02 GMT Subject: Integrated: JDK-8309340: Provide sctpHandleSocketErrorWithMessage In-Reply-To: References: Message-ID: On Fri, 2 Jun 2023 08:03:01 GMT, Matthias Baesken wrote: > There are cases in the sctp coding where a function sctpHandleSocketErrorWithMessage would be beneficial (similar to existing handleSocketErrorWithMessage) to provide more detail what failed. > > Additionally sctpHandleSocketErrorWithMessage was a bit modified (added errno handling for ENOTCONN from handleSocketErrorWithMessage). This pull request has now been integrated. Changeset: 3b85f84f Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/3b85f84f026973a2abdbce8d9baf1329c8a4ebf8 Stats: 20 lines in 2 files changed: 11 ins; 2 del; 7 mod 8309340: Provide sctpHandleSocketErrorWithMessage Reviewed-by: clanger ------------- PR: https://git.openjdk.org/jdk/pull/14280 From alanb at openjdk.org Tue Jun 6 07:19:03 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 6 Jun 2023 07:19:03 GMT Subject: RFR: JDK-8309340: Provide sctpHandleSocketErrorWithMessage In-Reply-To: References: Message-ID: On Fri, 2 Jun 2023 08:03:01 GMT, Matthias Baesken wrote: > There are cases in the sctp coding where a function sctpHandleSocketErrorWithMessage would be beneficial (similar to existing handleSocketErrorWithMessage) to provide more detail what failed. > > Additionally sctpHandleSocketErrorWithMessage was a bit modified (added errno handling for ENOTCONN from handleSocketErrorWithMessage). I see this was integrated without a reviewer in the area but I think the changes are okay. src/jdk.sctp/unix/native/libsctp/SctpNet.c line 147: > 145: errno = errorValue; > 146: if (message == NULL) { > 147: JNU_ThrowByNameWithLastError(env, xn, "NioSocketError"); "NioSocketError" is confusing as the failing message, maybe we should change that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14280#issuecomment-1578057691 PR Review Comment: https://git.openjdk.org/jdk/pull/14280#discussion_r1219054386 From mbaesken at openjdk.org Tue Jun 6 07:24:01 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 6 Jun 2023 07:24:01 GMT Subject: RFR: JDK-8309340: Provide sctpHandleSocketErrorWithMessage In-Reply-To: References:

Message-ID: On Tue, 6 Jun 2023 07:16:13 GMT, Alan Bateman wrote: > I see this was integrated without a reviewer in the area but I think the changes are okay. Hi Alan, I think Christoph is very competent in the area. But should I look into the census next time for some special reviewer category (and which one would that be) ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14280#issuecomment-1578063861 From alanb at openjdk.org Tue Jun 6 07:28:55 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 6 Jun 2023 07:28:55 GMT Subject: RFR: 8308807: [AIX] MulticastSocket and jdp test fails due to joinGroup In-Reply-To: References: <4tkYKvpBoxO7IK4HevAqpEY5KoqxXUK6rs0scqyxgJc=.69de9b21-5a2f-45ef-b05f-1bc8ad398dad@github.com> Message-ID: On Thu, 25 May 2023 07:37:27 GMT, Alan Bateman wrote: >> DatagramSocket delegates to an inner DatagramSocket object. Irrespective of whether datagramSocket is IPv4 or IPv6, we create an IPv6 datagramChannel as its's delegate. So, This can cause problems with operations like joinGroup. >> >> On AIX, IPv6 datagramSocket can not join an IPv4 multicast group. >> >> These failures can be fixed by making sure that the delegate created for a datagram socket has the same protocol family. >> >> >> >> >> Reported Issue : [JDK-8308807](https://bugs.openjdk.org/browse/JDK-8308807) > > I've moved the JBS issue to the right place and fix the description. > > The changes proposed here impact all platforms and will require discussion and cleanup. If I understand the intent, if you create a DatagramSocket or MulticastSocket that is bound to a specific local address then you want to use that to determine if the underlying socket is IPv4 or IPv6. That might be okay but multicasting normally means binding to the wildcard address so it doesn't help - I assume it only works for the test because new InetSocketAddress(port).getAddress() returns an Inet4Address so you get an IPv4 socket. It should only create a dual IPv4/IPv6 socket for this case so this is why it will break other platforms. In any case, can you look at the isXXX methods defined by sun.nio.ch.Net to see how it is handled on other platforms. > Yes, I agree with @AlanBateman and @msheppar . Even when we try to have an IPv4 multicast socket join an IPv4 multicast group, we still fail because the delegate that is created for an IPv4 multicast socket is IPv4/IPv6 (dual stack) in nature. AIX does not allow dual stack (IPv4/IPv6) sockets to join IPv4 multicast groups. The "Platform dependencies" in java.nio.channels.MulticastChannel (implemented by DatagramChannel) makes it clear that it is implementation specific as to whether a channel to an IPv6 socket can join an IPv4 multicast group. The recommendation is to specify the protocol family when creating the channel. Legacy DatagramSocket/MulticastSocket do not define a constructor that allows the protocol family be specified at xxxSocket create time. That issue has been there since JDK 1.4 when IPv6 support was added. I'm curious why this might be coming up with AIX now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14142#issuecomment-1578072460 From alanb at openjdk.org Tue Jun 6 07:35:07 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 6 Jun 2023 07:35:07 GMT Subject: RFR: JDK-8309340: Provide sctpHandleSocketErrorWithMessage In-Reply-To: References: Message-ID: On Fri, 2 Jun 2023 08:03:01 GMT, Matthias Baesken wrote: > There are cases in the sctp coding where a function sctpHandleSocketErrorWithMessage would be beneficial (similar to existing handleSocketErrorWithMessage) to provide more detail what failed. > > Additionally sctpHandleSocketErrorWithMessage was a bit modified (added errno handling for ENOTCONN from handleSocketErrorWithMessage). The SCTP API/implementation is the networking area, "net" group in the census. We usually try to get a Reviewer from that area for changes to the networking code. It's not an issue here, just mentioning it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14280#issuecomment-1578082485 From dfuchs at openjdk.org Tue Jun 6 08:54:01 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 6 Jun 2023 08:54:01 GMT Subject: RFR: JDK-8309340: Provide sctpHandleSocketErrorWithMessage In-Reply-To: References: Message-ID: On Fri, 2 Jun 2023 08:03:01 GMT, Matthias Baesken wrote: > There are cases in the sctp coding where a function sctpHandleSocketErrorWithMessage would be beneficial (similar to existing handleSocketErrorWithMessage) to provide more detail what failed. > > Additionally sctpHandleSocketErrorWithMessage was a bit modified (added errno handling for ENOTCONN from handleSocketErrorWithMessage). FWIW the changes look good to me. ------------- PR Review: https://git.openjdk.org/jdk/pull/14280#pullrequestreview-1464641236 From mbaesken at openjdk.org Tue Jun 6 10:41:01 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 6 Jun 2023 10:41:01 GMT Subject: RFR: JDK-8309340: Provide sctpHandleSocketErrorWithMessage In-Reply-To: References:

Message-ID: On Tue, 6 Jun 2023 08:51:33 GMT, Daniel Fuchs wrote: > FWIW the changes look good to me. Thanks for looking into it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14280#issuecomment-1578414732 From mbaesken at openjdk.org Tue Jun 6 10:41:04 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 6 Jun 2023 10:41:04 GMT Subject: RFR: JDK-8309340: Provide sctpHandleSocketErrorWithMessage In-Reply-To: References:

Message-ID: On Tue, 6 Jun 2023 07:15:08 GMT, Alan Bateman wrote: >> There are cases in the sctp coding where a function sctpHandleSocketErrorWithMessage would be beneficial (similar to existing handleSocketErrorWithMessage) to provide more detail what failed. >> >> Additionally sctpHandleSocketErrorWithMessage was a bit modified (added errno handling for ENOTCONN from handleSocketErrorWithMessage). > > src/jdk.sctp/unix/native/libsctp/SctpNet.c line 147: > >> 145: errno = errorValue; >> 146: if (message == NULL) { >> 147: JNU_ThrowByNameWithLastError(env, xn, "NioSocketError"); > > "NioSocketError" is confusing as the failing message, maybe we should change that. Hi Alan, do you have a good suggestion what to use instead ? Maybe "SCTP socket error" ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14280#discussion_r1219391449 From djelinski at openjdk.org Tue Jun 6 10:52:50 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 6 Jun 2023 10:52:50 GMT Subject: RFR: 8309527: Improve test proxy performance Message-ID: Please review this change to introduce buffering in the tunnelling proxy implementations. Copying network data one byte at a time is very inefficient. ProxyAuthDisabledSchemesSSL is 10 seconds faster (from 40 down to 30s) on my Windows machine with these changes. I did not quantify the improvements in other tests affected by this change; I only verified that they continue to pass. ------------- Commit messages: - Update copyright - Buffer transferred data Changes: https://git.openjdk.org/jdk/pull/14329/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14329&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8309527 Stats: 29 lines in 5 files changed: 5 ins; 0 del; 24 mod Patch: https://git.openjdk.org/jdk/pull/14329.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14329/head:pull/14329 PR: https://git.openjdk.org/jdk/pull/14329 From daniel.fuchs at oracle.com Tue Jun 6 11:22:21 2023 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 6 Jun 2023 12:22:21 +0100 Subject: [EXTERNAL] Re: Support for Keepalive Extended Socket Options On Windows In-Reply-To: References: <185edc7f-437d-5a75-35ef-6e39a38c9210@oracle.com> <8e0c41f8-f4fa-334f-c5d3-3d42b84a21d0@oracle.com> Message-ID: Hi Terry, I'm not sure what would be a good default value, but it could possibly be controlled by a system property allowing to override whatever we pick. best regards, -- daniel On 05/06/2023 20:52, Terry Chow (Simba Technologies Inc) wrote: > Hi Alan and Daniel, > > Agreed, having Windows support the keepalive options as it's done on > other platforms would be the best. But, lobbying them for that change > would be extremely difficult as it would be very significant change that > impacts the whole platform. > > What defaults values do you guys have in mind? I'm still hesitating on > persisting default values because the default values can vary between > machines. > > Thanks, > Terry > ------------------------------------------------------------------------ > *From:* Alan Bateman > *Sent:* June 4, 2023 7:32 AM > *To:* Daniel Fuchs ; Terry Chow (Simba > Technologies Inc) ; net-dev at openjdk.org > > *Subject:* [EXTERNAL] Re: Support for Keepalive Extended Socket Options > On Windows > [You don't often get email from alan.bateman at oracle.com. Learn why this > is important at https://aka.ms/LearnAboutSenderIdentification > ] > > On 04/06/2023 10:49, Daniel Fuchs wrote: >> Hi, >> >> Could we maybe cache the values in the SocketImpl/NIOSocketImpl >> implementation? >> >> IIRC we do something like that for SO_TIMEOUT already, since this >> is handled at NIO level. >> >> If we know the default value then setting one (when the other is >> not set) could set it with the supplied value for the one, and >> the default (or cached value) for the other? >> >> Get would then return the cached value (or possibly default >> value if not set?) >> >> We could also potentially set some sensible defaults when creating >> the socket. >> > Yes, this is what I was suggesting in PR14232 too but it will likely be > a disruptive change. It can be prototyped at least, then we can see how > we could turn it into something that is maintainable. The best outcome > would of course be for Windows to expose the socket options in the same > way as Linux, macOS and others. > > -Alan From dfuchs at openjdk.org Tue Jun 6 11:52:50 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 6 Jun 2023 11:52:50 GMT Subject: RFR: 8309527: Improve test proxy performance In-Reply-To: References: Message-ID: On Tue, 6 Jun 2023 09:19:20 GMT, Daniel Jeli?ski wrote: > Please review this change to introduce buffering in the tunnelling proxy implementations. > > Copying network data one byte at a time is very inefficient. ProxyAuthDisabledSchemesSSL is 10 seconds faster (from 40 down to 30s) on my Windows machine with these changes. > > I did not quantify the improvements in other tests affected by this change; I only verified that they continue to pass. Good finding! ------------- Marked as reviewed by dfuchs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14329#pullrequestreview-1464996226 From dfuchs at openjdk.org Tue Jun 6 14:51:55 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 6 Jun 2023 14:51:55 GMT Subject: RFR: 8305763 : Parsing a URI with an underscore goes through a silent exception, negatively impacting performance In-Reply-To: References:

Message-ID: On Tue, 16 May 2023 17:20:08 GMT, Dhamoder Nalla wrote: >>> I will work on addressing this to keep the old behavior unchanged. >> >> Please make sure to run the java/net/URI tests - and when these are successful, tier1, tier2 and tier3. > > Thanks @dfuch, > I have validated the following tests with the new change. > 1. JShell: > jshell> new URI("http://foo_bar:8080/").getHost() > $1 ==> null > > jshell> new URI("http://foo_bar:8080/").getPort() > $2 ==> -1 > > jshell> new URI("http://foobar:8080/").getHost() > $3 ==> "foobar" > > jshell> new URI("http://foobar:8080/").getPort() > $4 ==> 8080 > 2. all tests under "java/net/URI" passed as expected. > 3. no failures related my change in tier1, tier2 and tier3 tests. @dhanalla if you integrate this change I will sponsor it. Alternatively if you'd prefer to wait until after the fork that's fine by me. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13430#issuecomment-1578912063 From dfuchs at openjdk.org Tue Jun 6 14:56:53 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 6 Jun 2023 14:56:53 GMT Subject: RFR: 8305906: HttpClient may use incorrect key when finding pooled HTTP/2 connection for IPv6 address [v3] In-Reply-To: References: <3b7IrpY4XC5OYB3SWQ2O1xH_ZUdOn2TDhr1y8h2M2Uw=.0e4b095a-c071-444c-9f67-62b2611e7977@github.com> Message-ID: On Fri, 21 Apr 2023 01:26:35 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8305906? >> >> As noted in that issue, when IPv6 hosts are involved, the HttpClient on certain occasions can end up caching the connection with a key which doesn't match with the key which is then used in a subsequent request against the same target host. >> >> The commit in this PR now wraps the IPv6 address in a square bracket consistently so that the correct key is used both during storing the connection in the pool and when looking up. >> >> A new jtreg test has been added which reproduces this issue without the fix and verifies the fix. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > wrapping into brackets is no longer needed Marked as reviewed by dfuchs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13456#pullrequestreview-1465411030 From duke at openjdk.org Tue Jun 6 15:55:56 2023 From: duke at openjdk.org (Dhamoder Nalla) Date: Tue, 6 Jun 2023 15:55:56 GMT Subject: RFR: 8305763 : Parsing a URI with an underscore goes through a silent exception, negatively impacting performance In-Reply-To: References:

Message-ID: On Tue, 6 Jun 2023 14:49:23 GMT, Daniel Fuchs wrote: >> Thanks @dfuch, >> I have validated the following tests with the new change. >> 1. JShell: >> jshell> new URI("http://foo_bar:8080/").getHost() >> $1 ==> null >> >> jshell> new URI("http://foo_bar:8080/").getPort() >> $2 ==> -1 >> >> jshell> new URI("http://foobar:8080/").getHost() >> $3 ==> "foobar" >> >> jshell> new URI("http://foobar:8080/").getPort() >> $4 ==> 8080 >> 2. all tests under "java/net/URI" passed as expected. >> 3. no failures related my change in tier1, tier2 and tier3 tests. > > @dhanalla if you integrate this change I will sponsor it. Alternatively if you'd prefer to wait until after the fork that's fine by me. @dfuch, Thank you for review and sponsorship. I submitted for integration. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13430#issuecomment-1579029509 From v-terrychow at microsoft.com Tue Jun 6 22:42:45 2023 From: v-terrychow at microsoft.com (Terry Chow (Simba Technologies Inc)) Date: Tue, 6 Jun 2023 22:42:45 +0000 Subject: [EXTERNAL] Re: Support for Keepalive Extended Socket Options On Windows In-Reply-To: References: <185edc7f-437d-5a75-35ef-6e39a38c9210@oracle.com> <8e0c41f8-f4fa-334f-c5d3-3d42b84a21d0@oracle.com>

Message-ID: Hi Daniel, That sounds good. I like the idea of using a system property to override the defaults just in case. For the starting default values, 2hrs and 1s for idle time and interval time respectively are the officially documented defaults. So, we could start with these. Just to reiterate, to start off with the prototype: 1. Persist default values at the socket level in either SocketImpl or NIOSocketImpl 2. Allow default values to be overridden through system properties 3. Starting default values for idle time and interval time will be 2hrs and 1s Let me know if that's acceptable or if there's more to add. Thanks, Terry ________________________________ From: Daniel Fuchs Sent: June 6, 2023 4:22 AM To: Terry Chow (Simba Technologies Inc) ; Alan Bateman ; net-dev at openjdk.org Subject: Re: [EXTERNAL] Re: Support for Keepalive Extended Socket Options On Windows [You don't often get email from daniel.fuchs at oracle.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] Hi Terry, I'm not sure what would be a good default value, but it could possibly be controlled by a system property allowing to override whatever we pick. best regards, -- daniel On 05/06/2023 20:52, Terry Chow (Simba Technologies Inc) wrote: > Hi Alan and Daniel, > > Agreed, having Windows support the keepalive options as it's done on > other platforms would be the best. But, lobbying them for that change > would be extremely difficult as it would be very significant change that > impacts the whole platform. > > What defaults values do you guys have in mind? I'm still hesitating on > persisting default values because the default values can vary between > machines. > > Thanks, > Terry > ------------------------------------------------------------------------ > *From:* Alan Bateman > *Sent:* June 4, 2023 7:32 AM > *To:* Daniel Fuchs ; Terry Chow (Simba > Technologies Inc) ; net-dev at openjdk.org > > *Subject:* [EXTERNAL] Re: Support for Keepalive Extended Socket Options > On Windows > [You don't often get email from alan.bateman at oracle.com. Learn why this > is important at https://aka.ms/LearnAboutSenderIdentification > ] > > On 04/06/2023 10:49, Daniel Fuchs wrote: >> Hi, >> >> Could we maybe cache the values in the SocketImpl/NIOSocketImpl >> implementation? >> >> IIRC we do something like that for SO_TIMEOUT already, since this >> is handled at NIO level. >> >> If we know the default value then setting one (when the other is >> not set) could set it with the supplied value for the one, and >> the default (or cached value) for the other? >> >> Get would then return the cached value (or possibly default >> value if not set?) >> >> We could also potentially set some sensible defaults when creating >> the socket. >> > Yes, this is what I was suggesting in PR14232 too but it will likely be > a disruptive change. It can be prototyped at least, then we can see how > we could turn it into something that is maintainable. The best outcome > would of course be for Windows to expose the socket options in the same > way as Linux, macOS and others. > > -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpai at openjdk.org Wed Jun 7 01:02:48 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 7 Jun 2023 01:02:48 GMT Subject: RFR: 8305906: HttpClient may use incorrect key when finding pooled HTTP/2 connection for IPv6 address [v4] In-Reply-To: <3b7IrpY4XC5OYB3SWQ2O1xH_ZUdOn2TDhr1y8h2M2Uw=.0e4b095a-c071-444c-9f67-62b2611e7977@github.com> References: <3b7IrpY4XC5OYB3SWQ2O1xH_ZUdOn2TDhr1y8h2M2Uw=.0e4b095a-c071-444c-9f67-62b2611e7977@github.com> Message-ID: > Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8305906? > > As noted in that issue, when IPv6 hosts are involved, the HttpClient on certain occasions can end up caching the connection with a key which doesn't match with the key which is then used in a subsequent request against the same target host. > > The commit in this PR now wraps the IPv6 address in a square bracket consistently so that the correct key is used both during storing the connection in the pool and when looking up. > > A new jtreg test has been added which reproduces this issue without the fix and verifies the fix. Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge latest master branch changes - wrapping into brackets is no longer needed - use HttpRequestImpl.getAddress() to lookup cache key instead of HttpRequestImpl.getURI() - 8305906: HttpClient may use incorrect key when finding pooled HTTP/2 connection for IPv6 address ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13456/files - new: https://git.openjdk.org/jdk/pull/13456/files/96b92659..6db0ea8c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13456&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13456&range=02-03 Stats: 496381 lines in 5623 files changed: 413148 ins; 40702 del; 42531 mod Patch: https://git.openjdk.org/jdk/pull/13456.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13456/head:pull/13456 PR: https://git.openjdk.org/jdk/pull/13456 From serb at openjdk.org Wed Jun 7 04:18:01 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 7 Jun 2023 04:18:01 GMT Subject: RFR: 8304885: Reuse stale data to improve DNS resolver resiliency [v15] In-Reply-To: References:

Message-ID: On Thu, 1 Jun 2023 21:28:23 GMT, Sergey Bylokhov wrote: >> I would like to get preliminary feedback about the provided patch. >> >> Discussion on net-dev@ https://mail.openjdk.org/pipermail/net-dev/2023-March/020682.html >> >> One of the main issue I try to solve is how the cache handle the intermittent DNS server outages due to overloading or network connection. >> >> At the moment this cache can be configured by the application using the following two properties: >> (1) "networkaddress.cache.ttl"(30 sec) - cache policy for successful lookups >> (2) "networkaddress.cache.negative.ttl"(10 sec) - cache policy for negative lookups >> >> The default timeout for positive responses is good enough to "have recent dns-records" and to "minimize the number of requests to the DNS server". >> >> But the cache for the negative responses is problematic. This is a problem I would like to solve. Caching the negative response means that for **10** seconds the application will not be able to connect to the server. >> >> Possible solutions: >> 1. Decreasing timeout "for the negative responses": unfortunately more requests to the server at the moment of "DNS-outage" cause even more issues, since this is not the right moment to load the network/server more. >> 2. Increasing timeout "for the positive responses": this will decrease the chance to get an error, but the cache will start to use stale data longer. >> 3. This proposal: it would be good to ignore the negative response and continue to use the result of the last "successful lookup" until some additional timeout. >> >> The idea is to split the notion of the TTL and the timeout used for the cache. When TTL for the record will expire we should request the new data from the server. If this request goes fine we will update the record, if it fails we will continue to use the cached date until the next sync. >> >> For example, if the new property "networkaddress.cache.extended.ttl" is set to 10 minutes, then we will cache a positive response for 10 minutes but will try to sync it every 30 seconds. If the new property is not set then as before we will cache positive for 30 seconds and then cache the negative response for 10 seconds. >> >> >> RFC 8767 Serving Stale Data to Improve DNS Resiliency: >> https://www.rfc-editor.org/rfc/rfc8767 >> >> Comments about current and other possible implementations: >> * The code intentionally moved to the separate ValidAddresses class, just to make clear that the default configuration, when the new property is not set is not changed much. >> * The refr... > > Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision: > > Fix possible race in the SimpleResolverProviderImpl Does anybody have other comments or the PR is ready to be approved? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13285#issuecomment-1579855284 From jpai at openjdk.org Wed Jun 7 06:03:25 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 7 Jun 2023 06:03:25 GMT Subject: RFR: 8305906: HttpClient may use incorrect key when finding pooled HTTP/2 connection for IPv6 address [v5] In-Reply-To: <3b7IrpY4XC5OYB3SWQ2O1xH_ZUdOn2TDhr1y8h2M2Uw=.0e4b095a-c071-444c-9f67-62b2611e7977@github.com> References: <3b7IrpY4XC5OYB3SWQ2O1xH_ZUdOn2TDhr1y8h2M2Uw=.0e4b095a-c071-444c-9f67-62b2611e7977@github.com> Message-ID: > Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8305906? > > As noted in that issue, when IPv6 hosts are involved, the HttpClient on certain occasions can end up caching the connection with a key which doesn't match with the key which is then used in a subsequent request against the same target host. > > The commit in this PR now wraps the IPv6 address in a square bracket consistently so that the correct key is used both during storing the connection in the pool and when looking up. > > A new jtreg test has been added which reproduces this issue without the fix and verifies the fix. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: simplify the keyFor method to accept the entire HttpRequestImpl instance ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13456/files - new: https://git.openjdk.org/jdk/pull/13456/files/6db0ea8c..13821d88 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13456&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13456&range=03-04 Stats: 8 lines in 2 files changed: 2 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/13456.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13456/head:pull/13456 PR: https://git.openjdk.org/jdk/pull/13456 From jpai at openjdk.org Wed Jun 7 06:03:29 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 7 Jun 2023 06:03:29 GMT Subject: RFR: 8305906: HttpClient may use incorrect key when finding pooled HTTP/2 connection for IPv6 address [v4] In-Reply-To: References: <3b7IrpY4XC5OYB3SWQ2O1xH_ZUdOn2TDhr1y8h2M2Uw=.0e4b095a-c071-444c-9f67-62b2611e7977@github.com>

Message-ID: On Tue, 6 Jun 2023 14:53:40 GMT, Daniel Fuchs wrote: >> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: >> >> - Merge latest master branch changes >> - wrapping into brackets is no longer needed >> - use HttpRequestImpl.getAddress() to lookup cache key instead of HttpRequestImpl.getURI() >> - 8305906: HttpClient may use incorrect key when finding pooled HTTP/2 connection for IPv6 address > > Marked as reviewed by dfuchs (Reviewer). Hello @dfuch, @djelinski, I've done some minor changes to this PR to have `keyFor` accept a `HttpRequestImpl` instance so that it's clear where the `InetSocketAddress`es get sourced from when constructing the cache key. CI tests with this latest change continue to pass. Requesting a fresh review of this change, please. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13456#issuecomment-1579951670 From jpai at openjdk.org Wed Jun 7 06:27:53 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 7 Jun 2023 06:27:53 GMT Subject: RFR: 8309527: Improve test proxy performance In-Reply-To: References: Message-ID: On Tue, 6 Jun 2023 09:19:20 GMT, Daniel Jeli?ski wrote: > Please review this change to introduce buffering in the tunnelling proxy implementations. > > Copying network data one byte at a time is very inefficient. ProxyAuthDisabledSchemesSSL is 10 seconds faster (from 40 down to 30s) on my Windows machine with these changes. > > I did not quantify the improvements in other tests affected by this change; I only verified that they continue to pass. Hello Daniel, these changes look good to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14329#pullrequestreview-1466701145 From djelinski at openjdk.org Wed Jun 7 06:48:56 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 7 Jun 2023 06:48:56 GMT Subject: RFR: 8305906: HttpClient may use incorrect key when finding pooled HTTP/2 connection for IPv6 address [v5] In-Reply-To: References: <3b7IrpY4XC5OYB3SWQ2O1xH_ZUdOn2TDhr1y8h2M2Uw=.0e4b095a-c071-444c-9f67-62b2611e7977@github.com> Message-ID: On Wed, 7 Jun 2023 06:03:25 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8305906? >> >> As noted in that issue, when IPv6 hosts are involved, the HttpClient on certain occasions can end up caching the connection with a key which doesn't match with the key which is then used in a subsequent request against the same target host. >> >> The commit in this PR now wraps the IPv6 address in a square bracket consistently so that the correct key is used both during storing the connection in the pool and when looking up. >> >> A new jtreg test has been added which reproduces this issue without the fix and verifies the fix. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > simplify the keyFor method to accept the entire HttpRequestImpl instance Marked as reviewed by djelinski (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13456#pullrequestreview-1466736391 From djelinski at openjdk.org Wed Jun 7 07:54:05 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 7 Jun 2023 07:54:05 GMT Subject: Integrated: 8309527: Improve test proxy performance In-Reply-To: References: Message-ID: On Tue, 6 Jun 2023 09:19:20 GMT, Daniel Jeli?ski wrote: > Please review this change to introduce buffering in the tunnelling proxy implementations. > > Copying network data one byte at a time is very inefficient. ProxyAuthDisabledSchemesSSL is 10 seconds faster (from 40 down to 30s) on my Windows machine with these changes. > > I did not quantify the improvements in other tests affected by this change; I only verified that they continue to pass. This pull request has now been integrated. Changeset: fadcd650 Author: Daniel Jeli?ski URL: https://git.openjdk.org/jdk/commit/fadcd6501879af40360b217d2f76ab86a6f55d27 Stats: 29 lines in 5 files changed: 5 ins; 0 del; 24 mod 8309527: Improve test proxy performance Reviewed-by: dfuchs, jpai ------------- PR: https://git.openjdk.org/jdk/pull/14329 From bruno at bdasilva.com Wed Jun 7 06:17:08 2023 From: bruno at bdasilva.com (Bruno Da Silva) Date: Wed, 7 Jun 2023 02:17:08 -0400 Subject: Bug in ExtendedSocketOptions: TCP_QUICKACK can't be set in linux due to incorrect syscall level Message-ID: Hi all, Random SWE here. I've found a bug in the LinuxSocketOptions.c native implementation of getting/setting quickack on a socket. When running strace, the socket option that is set is actually changing the SO_PRIORITY. This is because the syscall is incorrectly called with level=SO_SOCKET rather than level=SOL_TCP. You can see this in the openjdk implementation on line 92 and 105: https://github.com/openjdk/jdk/blob/a08c5cb3f1be7a20c8f955951d1605bb8b1c1aa4/src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c#L92. It has existed since the original implementation in JDK-8145635. I believe the fix is to change both get/set syscalls like this: setsockopt(fd, SOL_SOCKET, TCP_QUICKACK, &optval, sizeof (optval)); to setsockopt(fd, SOL_TCP, TCP_QUICKACK, &optval, sizeof (optval)); The bug has existed since JDK 10 and I see it still exists in the most recent versions of Java. It was found and tested in JDK 11. As a non-contributor, I don't know of a way of submitting a patch or directly reporting this bug. Can someone provide guidance on where to take it from here? Thank you, Bruno Da Silva -------------- next part -------------- An HTML attachment was scrubbed... URL: From dfuchs at openjdk.org Wed Jun 7 09:38:58 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 7 Jun 2023 09:38:58 GMT Subject: RFR: 8305906: HttpClient may use incorrect key when finding pooled HTTP/2 connection for IPv6 address [v5] In-Reply-To: References: <3b7IrpY4XC5OYB3SWQ2O1xH_ZUdOn2TDhr1y8h2M2Uw=.0e4b095a-c071-444c-9f67-62b2611e7977@github.com> Message-ID: On Wed, 7 Jun 2023 06:03:25 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8305906? >> >> As noted in that issue, when IPv6 hosts are involved, the HttpClient on certain occasions can end up caching the connection with a key which doesn't match with the key which is then used in a subsequent request against the same target host. >> >> The commit in this PR now wraps the IPv6 address in a square bracket consistently so that the correct key is used both during storing the connection in the pool and when looking up. >> >> A new jtreg test has been added which reproduces this issue without the fix and verifies the fix. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > simplify the keyFor method to accept the entire HttpRequestImpl instance Marked as reviewed by dfuchs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13456#pullrequestreview-1467152670 From jpai at openjdk.org Wed Jun 7 09:47:07 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 7 Jun 2023 09:47:07 GMT Subject: RFR: 8305906: HttpClient may use incorrect key when finding pooled HTTP/2 connection for IPv6 address [v5] In-Reply-To: References: <3b7IrpY4XC5OYB3SWQ2O1xH_ZUdOn2TDhr1y8h2M2Uw=.0e4b095a-c071-444c-9f67-62b2611e7977@github.com> Message-ID: On Wed, 7 Jun 2023 06:03:25 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8305906? >> >> As noted in that issue, when IPv6 hosts are involved, the HttpClient on certain occasions can end up caching the connection with a key which doesn't match with the key which is then used in a subsequent request against the same target host. >> >> The commit in this PR now wraps the IPv6 address in a square bracket consistently so that the correct key is used both during storing the connection in the pool and when looking up. >> >> A new jtreg test has been added which reproduces this issue without the fix and verifies the fix. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > simplify the keyFor method to accept the entire HttpRequestImpl instance Thank you both for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13456#issuecomment-1580320817 From jpai at openjdk.org Wed Jun 7 09:47:15 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 7 Jun 2023 09:47:15 GMT Subject: Integrated: 8305906: HttpClient may use incorrect key when finding pooled HTTP/2 connection for IPv6 address In-Reply-To: <3b7IrpY4XC5OYB3SWQ2O1xH_ZUdOn2TDhr1y8h2M2Uw=.0e4b095a-c071-444c-9f67-62b2611e7977@github.com> References: <3b7IrpY4XC5OYB3SWQ2O1xH_ZUdOn2TDhr1y8h2M2Uw=.0e4b095a-c071-444c-9f67-62b2611e7977@github.com> Message-ID: On Thu, 13 Apr 2023 11:13:07 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8305906? > > As noted in that issue, when IPv6 hosts are involved, the HttpClient on certain occasions can end up caching the connection with a key which doesn't match with the key which is then used in a subsequent request against the same target host. > > The commit in this PR now wraps the IPv6 address in a square bracket consistently so that the correct key is used both during storing the connection in the pool and when looking up. > > A new jtreg test has been added which reproduces this issue without the fix and verifies the fix. This pull request has now been integrated. Changeset: 3ccb3c0e Author: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/3ccb3c0e09f9a414229d3f76031f3fc8f271c936 Stats: 194 lines in 3 files changed: 183 ins; 4 del; 7 mod 8305906: HttpClient may use incorrect key when finding pooled HTTP/2 connection for IPv6 address Reviewed-by: djelinski, dfuchs ------------- PR: https://git.openjdk.org/jdk/pull/13456 From Alan.Bateman at oracle.com Wed Jun 7 09:50:31 2023 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 7 Jun 2023 10:50:31 +0100 Subject: Bug in ExtendedSocketOptions: TCP_QUICKACK can't be set in linux due to incorrect syscall level In-Reply-To: References: Message-ID: <1492ff1f-b501-9557-5159-9592d29db953@oracle.com> On 07/06/2023 07:17, Bruno Da Silva wrote: > Hi all, > > Random SWE here. I've found a bug in the LinuxSocketOptions.c native > implementation of getting/setting quickack on a socket. When running > strace, the socket option that is set is actually changing the > SO_PRIORITY. > > This is because the syscall is incorrectly called with level=SO_SOCKET > rather than level=SOL_TCP. You can see this in the openjdk > implementation on line 92 and 105: > https://github.com/openjdk/jdk/blob/a08c5cb3f1be7a20c8f955951d1605bb8b1c1aa4/src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c#L92. > It has existed since the original implementation in?JDK-8145635. > > I believe the fix is to change both get/set syscalls like this: > setsockopt(fd, SOL_SOCKET, TCP_QUICKACK, &optval, sizeof (optval)); > to > setsockopt(fd, SOL_TCP, TCP_QUICKACK, &optval, sizeof (optval)); > > The bug has existed since JDK 10 and I see it still exists in the most > recent versions of Java. It was found and tested in JDK 11. > > > As a non-contributor, I don't know of?a way of submitting a patch or > directly reporting this bug. Can someone provide guidance on where to > take it from here? > Good find, I've created JDK-8309591 [1] to track it. Create a PR if you want to run with this, otherwise someone else will need to pick this up. -Alan [1] https://bugs.openjdk.org/browse/JDK-8309591 From duke at openjdk.org Wed Jun 7 09:53:08 2023 From: duke at openjdk.org (Dhamoder Nalla) Date: Wed, 7 Jun 2023 09:53:08 GMT Subject: Integrated: 8305763 : Parsing a URI with an underscore goes through a silent exception, negatively impacting performance In-Reply-To: References: Message-ID: On Tue, 11 Apr 2023 18:00:05 GMT, Dhamoder Nalla wrote: > Issue 8305763 : Using underscores in the name for a URI triggers a silent exception in the java standard library, which consumes 5% of the CPU. > > Exception: > java.net.URISyntaxException: Illegal character in hostname at index N: xyz1_abcd.com > at java.base/java.net.URI$Parser.fail(URI.java:2943) > at java.base/java.net.URI$Parser.parseHostname(URI.java:3487) > at java.base/java.net.URI$Parser.parseServer(URI.java:3329) > > This exception is silent and does not produce any messages, except for ODP profiler, there is no other evidence that it?s happening (the stack trace above was printed after changes to Java library). The reason for this is because of how the URI creation is implemented in the java.net.URI class. There are two paths for creating a valid URI, and one of them goes through an exception. > > We can see that if parseServer fails, there is still a way the authority gets assigned and we don?t throw an exception from the method. This means, not being able to parse the server is ok and the exception is silenced. In our case, the server parsing fails because we find an illegal character, as only alphanumeric and dash characters are allowed. This pull request has now been integrated. Changeset: 749d4801 Author: Dhamoder Nalla Committer: Daniel Fuchs URL: https://git.openjdk.org/jdk/commit/749d4801937ac145f945765f0ba0980bbccf384f Stats: 29 lines in 1 file changed: 20 ins; 0 del; 9 mod 8305763: Parsing a URI with an underscore goes through a silent exception, negatively impacting performance Reviewed-by: dfuchs ------------- PR: https://git.openjdk.org/jdk/pull/13430 From msheppar at openjdk.org Wed Jun 7 10:13:55 2023 From: msheppar at openjdk.org (Mark Sheppard) Date: Wed, 7 Jun 2023 10:13:55 GMT Subject: RFR: 8308336: Test java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java failed: java.net.BindException: Address already in use In-Reply-To: References:

Message-ID: On Fri, 26 May 2023 13:34:08 GMT, Daniel Fuchs wrote: >> `HttpURLConnectionExpectContinueTest` was throwing an error due to port being hardcoded, updated test to let the system decide which port to use. > > test/jdk/java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java line 76: > >> 74: control.serverSocket = new ServerSocket(); >> 75: control.serverSocket.setReuseAddress(true); >> 76: control.serverSocket.bind(new InetSocketAddress("127.0.0.1", 0)); > > While you're at it can you change the address to use `InetAddress.getLoopbackAddress()`here, and the URIBuilder in createConnection() below? based on Daniel's last comment and requested change then I think it would be useful to add two additional run requests to the test which set the network properties java.net.preferIPv4Stack=true and java.net.preferIPv6Addresses=true, for completeness. You never know what might "pop out of the woodwork" ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14177#discussion_r1221321072 From jai.forums2013 at gmail.com Wed Jun 7 10:18:49 2023 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Wed, 7 Jun 2023 15:48:49 +0530 Subject: Bug in ExtendedSocketOptions: TCP_QUICKACK can't be set in linux due to incorrect syscall level In-Reply-To: <1492ff1f-b501-9557-5159-9592d29db953@oracle.com> References: <1492ff1f-b501-9557-5159-9592d29db953@oracle.com> Message-ID: Hello Bruno, Alan has created the JBS issue to track this. In order to submit a patch, you can follow the guidelines that are available at https://openjdk.org/guide/ -Jaikiran On 07/06/23 3:20 pm, Alan Bateman wrote: > On 07/06/2023 07:17, Bruno Da Silva wrote: >> Hi all, >> >> Random SWE here. I've found a bug in the LinuxSocketOptions.c native >> implementation of getting/setting quickack on a socket. When running >> strace, the socket option that is set is actually changing the >> SO_PRIORITY. >> >> This is because the syscall is incorrectly called with >> level=SO_SOCKET rather than level=SOL_TCP. You can see this in the >> openjdk implementation on line 92 and 105: >> https://github.com/openjdk/jdk/blob/a08c5cb3f1be7a20c8f955951d1605bb8b1c1aa4/src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c#L92. >> It has existed since the original implementation in?JDK-8145635. >> >> I believe the fix is to change both get/set syscalls like this: >> setsockopt(fd, SOL_SOCKET, TCP_QUICKACK, &optval, sizeof (optval)); >> to >> setsockopt(fd, SOL_TCP, TCP_QUICKACK, &optval, sizeof (optval)); >> >> The bug has existed since JDK 10 and I see it still exists in the >> most recent versions of Java. It was found and tested in JDK 11. >> >> >> As a non-contributor, I don't know of?a way of submitting a patch or >> directly reporting this bug. Can someone provide guidance on where to >> take it from here? >> > Good find, I've created JDK-8309591 [1] to track it. Create a PR if > you want to run with this, otherwise someone else will need to pick > this up. > > -Alan > > [1] https://bugs.openjdk.org/browse/JDK-8309591 From djelinski1 at gmail.com Wed Jun 7 12:48:27 2023 From: djelinski1 at gmail.com (=?UTF-8?Q?Daniel_Jeli=C5=84ski?=) Date: Wed, 7 Jun 2023 14:48:27 +0200 Subject: [EXTERNAL] Re: Support for Keepalive Extended Socket Options On Windows In-Reply-To: References: <185edc7f-437d-5a75-35ef-6e39a38c9210@oracle.com> <8e0c41f8-f4fa-334f-c5d3-3d42b84a21d0@oracle.com>

Message-ID: FWIW, TCP_KEEPIDLE and TCP_KEEPINTVL are available on Windows, starting with Windows 10, version 1709: https://learn.microsoft.com/en-us/windows/win32/winsock/ipproto-tcp-socket-options Apparently TCP_KEEPCNT is available too. Can we use these options and wait for older Windows versions to go out of support? Regards, Daniel ?r., 7 cze 2023 o 00:43 Terry Chow (Simba Technologies Inc) napisa?(a): > > Hi Daniel, > > That sounds good. I like the idea of using a system property to override the defaults just in case. For the starting default values, 2hrs and 1s for idle time and interval time respectively are the officially documented defaults. So, we could start with these. > > Just to reiterate, to start off with the prototype: > > Persist default values at the socket level in either SocketImpl or NIOSocketImpl > Allow default values to be overridden through system properties > Starting default values for idle time and interval time will be 2hrs and 1s > > Let me know if that's acceptable or if there's more to add. > > Thanks, > Terry > ________________________________ > From: Daniel Fuchs > Sent: June 6, 2023 4:22 AM > To: Terry Chow (Simba Technologies Inc) ; Alan Bateman ; net-dev at openjdk.org > Subject: Re: [EXTERNAL] Re: Support for Keepalive Extended Socket Options On Windows > > [You don't often get email from daniel.fuchs at oracle.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] > > Hi Terry, > > I'm not sure what would be a good default value, but it could > possibly be controlled by a system property allowing to override > whatever we pick. > > best regards, > > -- daniel > > > On 05/06/2023 20:52, Terry Chow (Simba Technologies Inc) wrote: > > Hi Alan and Daniel, > > > > Agreed, having Windows support the keepalive options as it's done on > > other platforms would be the best. But, lobbying them for that change > > would be extremely difficult as it would be very significant change that > > impacts the whole platform. > > > > What defaults values do you guys have in mind? I'm still hesitating on > > persisting default values because the default values can vary between > > machines. > > > > Thanks, > > Terry > > ------------------------------------------------------------------------ > > *From:* Alan Bateman > > *Sent:* June 4, 2023 7:32 AM > > *To:* Daniel Fuchs ; Terry Chow (Simba > > Technologies Inc) ; net-dev at openjdk.org > > > > *Subject:* [EXTERNAL] Re: Support for Keepalive Extended Socket Options > > On Windows > > [You don't often get email from alan.bateman at oracle.com. Learn why this > > is important at https://aka.ms/LearnAboutSenderIdentification > > ] > > > > On 04/06/2023 10:49, Daniel Fuchs wrote: > >> Hi, > >> > >> Could we maybe cache the values in the SocketImpl/NIOSocketImpl > >> implementation? > >> > >> IIRC we do something like that for SO_TIMEOUT already, since this > >> is handled at NIO level. > >> > >> If we know the default value then setting one (when the other is > >> not set) could set it with the supplied value for the one, and > >> the default (or cached value) for the other? > >> > >> Get would then return the cached value (or possibly default > >> value if not set?) > >> > >> We could also potentially set some sensible defaults when creating > >> the socket. > >> > > Yes, this is what I was suggesting in PR14232 too but it will likely be > > a disruptive change. It can be prototyped at least, then we can see how > > we could turn it into something that is maintainable. The best outcome > > would of course be for Windows to expose the socket options in the same > > way as Linux, macOS and others. > > > > -Alan > From bruno at bdasilva.com Wed Jun 7 10:52:41 2023 From: bruno at bdasilva.com (Bruno Da Silva) Date: Wed, 7 Jun 2023 06:52:41 -0400 Subject: Bug in ExtendedSocketOptions: TCP_QUICKACK can't be set in linux due to incorrect syscall level In-Reply-To: References: <1492ff1f-b501-9557-5159-9592d29db953@oracle.com> Message-ID: Thanks, @Alan and @Jaikiran :) I'll set myself up to submit a patch and reply to this chain once one is ready for review. Bruno On Wed, Jun 7, 2023 at 6:18?AM Jaikiran Pai wrote: > Hello Bruno, > > Alan has created the JBS issue to track this. In order to submit a > patch, you can follow the guidelines that are available at > https://openjdk.org/guide/ > > -Jaikiran > > On 07/06/23 3:20 pm, Alan Bateman wrote: > > On 07/06/2023 07:17, Bruno Da Silva wrote: > >> Hi all, > >> > >> Random SWE here. I've found a bug in the LinuxSocketOptions.c native > >> implementation of getting/setting quickack on a socket. When running > >> strace, the socket option that is set is actually changing the > >> SO_PRIORITY. > >> > >> This is because the syscall is incorrectly called with > >> level=SO_SOCKET rather than level=SOL_TCP. You can see this in the > >> openjdk implementation on line 92 and 105: > >> > https://github.com/openjdk/jdk/blob/a08c5cb3f1be7a20c8f955951d1605bb8b1c1aa4/src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c#L92. > > >> It has existed since the original implementation in JDK-8145635. > >> > >> I believe the fix is to change both get/set syscalls like this: > >> setsockopt(fd, SOL_SOCKET, TCP_QUICKACK, &optval, sizeof (optval)); > >> to > >> setsockopt(fd, SOL_TCP, TCP_QUICKACK, &optval, sizeof (optval)); > >> > >> The bug has existed since JDK 10 and I see it still exists in the > >> most recent versions of Java. It was found and tested in JDK 11. > >> > >> > >> As a non-contributor, I don't know of a way of submitting a patch or > >> directly reporting this bug. Can someone provide guidance on where to > >> take it from here? > >> > > Good find, I've created JDK-8309591 [1] to track it. Create a PR if > > you want to run with this, otherwise someone else will need to pick > > this up. > > > > -Alan > > > > [1] https://bugs.openjdk.org/browse/JDK-8309591 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serb at openjdk.org Wed Jun 7 19:04:15 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 7 Jun 2023 19:04:15 GMT Subject: RFR: 8304885: Reuse stale data to improve DNS resolver resiliency [v16] In-Reply-To: References: Message-ID: > I would like to get preliminary feedback about the provided patch. > > Discussion on net-dev@ https://mail.openjdk.org/pipermail/net-dev/2023-March/020682.html > > One of the main issue I try to solve is how the cache handle the intermittent DNS server outages due to overloading or network connection. > > At the moment this cache can be configured by the application using the following two properties: > (1) "networkaddress.cache.ttl"(30 sec) - cache policy for successful lookups > (2) "networkaddress.cache.negative.ttl"(10 sec) - cache policy for negative lookups > > The default timeout for positive responses is good enough to "have recent dns-records" and to "minimize the number of requests to the DNS server". > > But the cache for the negative responses is problematic. This is a problem I would like to solve. Caching the negative response means that for **10** seconds the application will not be able to connect to the server. > > Possible solutions: > 1. Decreasing timeout "for the negative responses": unfortunately more requests to the server at the moment of "DNS-outage" cause even more issues, since this is not the right moment to load the network/server more. > 2. Increasing timeout "for the positive responses": this will decrease the chance to get an error, but the cache will start to use stale data longer. > 3. This proposal: it would be good to ignore the negative response and continue to use the result of the last "successful lookup" until some additional timeout. > > The idea is to split the notion of the TTL and the timeout used for the cache. When TTL for the record will expire we should request the new data from the server. If this request goes fine we will update the record, if it fails we will continue to use the cached date until the next sync. > > For example, if the new property "networkaddress.cache.extended.ttl" is set to 10 minutes, then we will cache a positive response for 10 minutes but will try to sync it every 30 seconds. If the new property is not set then as before we will cache positive for 30 seconds and then cache the negative response for 10 seconds. > > > RFC 8767 Serving Stale Data to Improve DNS Resiliency: > https://www.rfc-editor.org/rfc/rfc8767 > > Comments about current and other possible implementations: > * The code intentionally moved to the separate ValidAddresses class, just to make clear that the default configuration, when the new property is not set is not changed much. > * The refresh timeout includes the time spent on the server lookup. So... Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision: CSR feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13285/files - new: https://git.openjdk.org/jdk/pull/13285/files/7bb0de6f..5397b790 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13285&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13285&range=14-15 Stats: 11 lines in 2 files changed: 2 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/13285.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13285/head:pull/13285 PR: https://git.openjdk.org/jdk/pull/13285 From v-terrychow at microsoft.com Thu Jun 8 02:00:26 2023 From: v-terrychow at microsoft.com (Terry Chow (Simba Technologies Inc)) Date: Thu, 8 Jun 2023 02:00:26 +0000 Subject: [EXTERNAL] Re: Support for Keepalive Extended Socket Options On Windows In-Reply-To: References: <185edc7f-437d-5a75-35ef-6e39a38c9210@oracle.com> <8e0c41f8-f4fa-334f-c5d3-3d42b84a21d0@oracle.com>

Message-ID: Hi Daniel Jeli?ski, Thanks for pointing that out. I completely overlooked that doc page. That definitely does look like the best way to conform to how things currently are. There shouldn't be any protest from my team on waiting out older Windows versions (I'll need to double check though). Thanks, Terry ________________________________ From: Daniel Jeli?ski Sent: June 7, 2023 5:48 AM To: Terry Chow (Simba Technologies Inc) Cc: Daniel Fuchs ; Alan Bateman ; net-dev at openjdk.org Subject: Re: [EXTERNAL] Re: Support for Keepalive Extended Socket Options On Windows [You don't often get email from djelinski1 at gmail.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] FWIW, TCP_KEEPIDLE and TCP_KEEPINTVL are available on Windows, starting with Windows 10, version 1709: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flearn.microsoft.com%2Fen-us%2Fwindows%2Fwin32%2Fwinsock%2Fipproto-tcp-socket-options&data=05%7C01%7Cv-terrychow%40microsoft.com%7C0dbf70ca1ce047e8370408db675584b8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638217389237258798%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=JVQxjufRqw84LssZX%2BmRNRxf8tH3OEriTzmWc5tSE8E%3D&reserved=0 Apparently TCP_KEEPCNT is available too. Can we use these options and wait for older Windows versions to go out of support? Regards, Daniel ?r., 7 cze 2023 o 00:43 Terry Chow (Simba Technologies Inc) napisa?(a): > > Hi Daniel, > > That sounds good. I like the idea of using a system property to override the defaults just in case. For the starting default values, 2hrs and 1s for idle time and interval time respectively are the officially documented defaults. So, we could start with these. > > Just to reiterate, to start off with the prototype: > > Persist default values at the socket level in either SocketImpl or NIOSocketImpl > Allow default values to be overridden through system properties > Starting default values for idle time and interval time will be 2hrs and 1s > > Let me know if that's acceptable or if there's more to add. > > Thanks, > Terry > ________________________________ > From: Daniel Fuchs > Sent: June 6, 2023 4:22 AM > To: Terry Chow (Simba Technologies Inc) ; Alan Bateman ; net-dev at openjdk.org > Subject: Re: [EXTERNAL] Re: Support for Keepalive Extended Socket Options On Windows > > [You don't often get email from daniel.fuchs at oracle.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] > > Hi Terry, > > I'm not sure what would be a good default value, but it could > possibly be controlled by a system property allowing to override > whatever we pick. > > best regards, > > -- daniel > > > On 05/06/2023 20:52, Terry Chow (Simba Technologies Inc) wrote: > > Hi Alan and Daniel, > > > > Agreed, having Windows support the keepalive options as it's done on > > other platforms would be the best. But, lobbying them for that change > > would be extremely difficult as it would be very significant change that > > impacts the whole platform. > > > > What defaults values do you guys have in mind? I'm still hesitating on > > persisting default values because the default values can vary between > > machines. > > > > Thanks, > > Terry > > ------------------------------------------------------------------------ > > *From:* Alan Bateman > > *Sent:* June 4, 2023 7:32 AM > > *To:* Daniel Fuchs ; Terry Chow (Simba > > Technologies Inc) ; net-dev at openjdk.org > > > > *Subject:* [EXTERNAL] Re: Support for Keepalive Extended Socket Options > > On Windows > > [You don't often get email from alan.bateman at oracle.com. Learn why this > > is important at https://aka.ms/LearnAboutSenderIdentification > > > ] > > > > On 04/06/2023 10:49, Daniel Fuchs wrote: > >> Hi, > >> > >> Could we maybe cache the values in the SocketImpl/NIOSocketImpl > >> implementation? > >> > >> IIRC we do something like that for SO_TIMEOUT already, since this > >> is handled at NIO level. > >> > >> If we know the default value then setting one (when the other is > >> not set) could set it with the supplied value for the one, and > >> the default (or cached value) for the other? > >> > >> Get would then return the cached value (or possibly default > >> value if not set?) > >> > >> We could also potentially set some sensible defaults when creating > >> the socket. > >> > > Yes, this is what I was suggesting in PR14232 too but it will likely be > > a disruptive change. It can be prototyped at least, then we can see how > > we could turn it into something that is maintainable. The best outcome > > would of course be for Windows to expose the socket options in the same > > way as Linux, macOS and others. > > > > -Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Thu Jun 8 14:09:01 2023 From: duke at openjdk.org (Darragh Clarke) Date: Thu, 8 Jun 2023 14:09:01 GMT Subject: RFR: 8308336: Test java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java failed: java.net.BindException: Address already in use [v2] In-Reply-To: References: Message-ID: > `HttpURLConnectionExpectContinueTest` was throwing an error due to port being hardcoded, updated test to let the system decide which port to use. Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision: implemented feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14177/files - new: https://git.openjdk.org/jdk/pull/14177/files/be625cf6..49b77cbc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14177&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14177&range=00-01 Stats: 10 lines in 1 file changed: 7 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/14177.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14177/head:pull/14177 PR: https://git.openjdk.org/jdk/pull/14177 From duke at openjdk.org Thu Jun 8 14:14:50 2023 From: duke at openjdk.org (Darragh Clarke) Date: Thu, 8 Jun 2023 14:14:50 GMT Subject: RFR: 8308336: Test java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java failed: java.net.BindException: Address already in use [v2] In-Reply-To: References:

Message-ID: On Wed, 7 Jun 2023 10:11:22 GMT, Mark Sheppard wrote: >> test/jdk/java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java line 76: >> >>> 74: control.serverSocket = new ServerSocket(); >>> 75: control.serverSocket.setReuseAddress(true); >>> 76: control.serverSocket.bind(new InetSocketAddress("127.0.0.1", 0)); >> >> While you're at it can you change the address to use `InetAddress.getLoopbackAddress()`here, and the URIBuilder in createConnection() below? > > based on Daniel's last comment and requested change then I think it would be useful to add two additional run requests to the test which set the network properties java.net.preferIPv4Stack=true and java.net.preferIPv6Addresses=true, for completeness. > You never know what might "pop out of the woodwork" I added those changes and verified that the tests are still passing ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14177#discussion_r1223102358 From serb at openjdk.org Thu Jun 8 14:18:10 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 8 Jun 2023 14:18:10 GMT Subject: RFR: 8304885: Reuse stale data to improve DNS resolver resiliency [v17] In-Reply-To: References: Message-ID: > I would like to get preliminary feedback about the provided patch. > > Discussion on net-dev@ https://mail.openjdk.org/pipermail/net-dev/2023-March/020682.html > > One of the main issue I try to solve is how the cache handle the intermittent DNS server outages due to overloading or network connection. > > At the moment this cache can be configured by the application using the following two properties: > (1) "networkaddress.cache.ttl"(30 sec) - cache policy for successful lookups > (2) "networkaddress.cache.negative.ttl"(10 sec) - cache policy for negative lookups > > The default timeout for positive responses is good enough to "have recent dns-records" and to "minimize the number of requests to the DNS server". > > But the cache for the negative responses is problematic. This is a problem I would like to solve. Caching the negative response means that for **10** seconds the application will not be able to connect to the server. > > Possible solutions: > 1. Decreasing timeout "for the negative responses": unfortunately more requests to the server at the moment of "DNS-outage" cause even more issues, since this is not the right moment to load the network/server more. > 2. Increasing timeout "for the positive responses": this will decrease the chance to get an error, but the cache will start to use stale data longer. > 3. This proposal: it would be good to ignore the negative response and continue to use the result of the last "successful lookup" until some additional timeout. > > The idea is to split the notion of the TTL and the timeout used for the cache. When TTL for the record will expire we should request the new data from the server. If this request goes fine we will update the record, if it fails we will continue to use the cached date until the next sync. > > For example, if the new property "networkaddress.cache.extended.ttl" is set to 10 minutes, then we will cache a positive response for 10 minutes but will try to sync it every 30 seconds. If the new property is not set then as before we will cache positive for 30 seconds and then cache the negative response for 10 seconds. > > > RFC 8767 Serving Stale Data to Improve DNS Resiliency: > https://www.rfc-editor.org/rfc/rfc8767 > > Comments about current and other possible implementations: > * The code intentionally moved to the separate ValidAddresses class, just to make clear that the default configuration, when the new property is not set is not changed much. > * The refresh timeout includes the time spent on the server lookup. So... Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision: CSR feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13285/files - new: https://git.openjdk.org/jdk/pull/13285/files/5397b790..aa6c12ea Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13285&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13285&range=15-16 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13285.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13285/head:pull/13285 PR: https://git.openjdk.org/jdk/pull/13285 From msheppar at openjdk.org Thu Jun 8 14:27:55 2023 From: msheppar at openjdk.org (Mark Sheppard) Date: Thu, 8 Jun 2023 14:27:55 GMT Subject: RFR: 8308336: Test java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java failed: java.net.BindException: Address already in use [v2] In-Reply-To: References:

Message-ID: On Thu, 8 Jun 2023 14:09:01 GMT, Darragh Clarke wrote: >> `HttpURLConnectionExpectContinueTest` was throwing an error due to port being hardcoded, updated test to let the system decide which port to use. > > Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision: > > implemented feedback test/jdk/java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java line 428: > 426: URL url = URIBuilder.newBuilder() > 427: .scheme("http") > 428: .host(InetAddress.getLoopbackAddress()) This will change the call flow of the test in a slightly subtle way. In the original the "host" is supplied i.e. localhost which should map to the loopback address, and in the change the loopback IP address is being supplied diectly. In terms of equivalence then supplying a host string might be more appropriate: .host("localhost") ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14177#discussion_r1223122614 From dfuchs at openjdk.org Thu Jun 8 15:10:51 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 8 Jun 2023 15:10:51 GMT Subject: RFR: 8308336: Test java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java failed: java.net.BindException: Address already in use [v2] In-Reply-To: References:

Message-ID: On Thu, 8 Jun 2023 14:25:20 GMT, Mark Sheppard wrote: >> Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision: >> >> implemented feedback > > test/jdk/java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java line 428: > >> 426: URL url = URIBuilder.newBuilder() >> 427: .scheme("http") >> 428: .host(InetAddress.getLoopbackAddress()) > > This will change the call flow of the test in a slightly subtle way. In the original the "host" is supplied i.e. localhost which should map to the loopback address, and in the change the loopback IP address is being supplied diectly. In terms of equivalence then supplying a host string might be more appropriate: > .host("localhost") No that's precisely what we want to avoid. Because how "localhost" maps to an InetAddress depends on the machine configuration, which is a recipe for intermittent failures. I'd suggest: URL url = URIBuilder.newBuilder() .scheme("http") .localhost() (which is actually the same) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14177#discussion_r1223187935 From dfuchs at openjdk.org Thu Jun 8 15:13:52 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 8 Jun 2023 15:13:52 GMT Subject: RFR: 8308336: Test java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java failed: java.net.BindException: Address already in use [v2] In-Reply-To: References:

Message-ID: On Thu, 8 Jun 2023 14:09:01 GMT, Darragh Clarke wrote: >> `HttpURLConnectionExpectContinueTest` was throwing an error due to port being hardcoded, updated test to let the system decide which port to use. > > Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision: > > implemented feedback test/jdk/java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java line 31: > 29: * @run junit/othervm HttpURLConnectionExpectContinueTest > 30: * @run junit/othervm -Djava.net.preferIPv4Stack=True HttpURLConnectionExpectContinueTest > 31: * @run junit/othervm -Djava.net.preferIPv6Addresses=True HttpURLConnectionExpectContinueTest Suggestion: * @run junit/othervm -Djava.net.preferIPv4Stack=true HttpURLConnectionExpectContinueTest * @run junit/othervm -Djava.net.preferIPv6Addresses=true HttpURLConnectionExpectContinueTest ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14177#discussion_r1223190801 From dfuchs at openjdk.org Thu Jun 8 15:24:57 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 8 Jun 2023 15:24:57 GMT Subject: RFR: 8304885: Reuse stale data to improve DNS resolver resiliency [v17] In-Reply-To: References:

Message-ID: On Thu, 8 Jun 2023 14:18:10 GMT, Sergey Bylokhov wrote: >> I would like to get preliminary feedback about the provided patch. >> >> Discussion on net-dev@ https://mail.openjdk.org/pipermail/net-dev/2023-March/020682.html >> >> One of the main issue I try to solve is how the cache handle the intermittent DNS server outages due to overloading or network connection. >> >> At the moment this cache can be configured by the application using the following two properties: >> (1) "networkaddress.cache.ttl"(30 sec) - cache policy for successful lookups >> (2) "networkaddress.cache.negative.ttl"(10 sec) - cache policy for negative lookups >> >> The default timeout for positive responses is good enough to "have recent dns-records" and to "minimize the number of requests to the DNS server". >> >> But the cache for the negative responses is problematic. This is a problem I would like to solve. Caching the negative response means that for **10** seconds the application will not be able to connect to the server. >> >> Possible solutions: >> 1. Decreasing timeout "for the negative responses": unfortunately more requests to the server at the moment of "DNS-outage" cause even more issues, since this is not the right moment to load the network/server more. >> 2. Increasing timeout "for the positive responses": this will decrease the chance to get an error, but the cache will start to use stale data longer. >> 3. This proposal: it would be good to ignore the negative response and continue to use the result of the last "successful lookup" until some additional timeout. >> >> The idea is to split the notion of the TTL and the timeout used for the cache. When TTL for the record will expire we should request the new data from the server. If this request goes fine we will update the record, if it fails we will continue to use the cached date until the next sync. >> >> For example, if the new property "networkaddress.cache.extended.ttl" is set to 10 minutes, then we will cache a positive response for 10 minutes but will try to sync it every 30 seconds. If the new property is not set then as before we will cache positive for 30 seconds and then cache the negative response for 10 seconds. >> >> >> RFC 8767 Serving Stale Data to Improve DNS Resiliency: >> https://www.rfc-editor.org/rfc/rfc8767 >> >> Comments about current and other possible implementations: >> * The code intentionally moved to the separate ValidAddresses class, just to make clear that the default configuration, when the new property is not set is not changed much. >> * The refr... > > Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision: > > CSR feedback Thanks for this later change. I agree with Alan that it does look better. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13285#issuecomment-1582807740 From duke at openjdk.org Thu Jun 8 15:53:03 2023 From: duke at openjdk.org (Darragh Clarke) Date: Thu, 8 Jun 2023 15:53:03 GMT Subject: RFR: 8308336: Test java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java failed: java.net.BindException: Address already in use [v3] In-Reply-To: References: Message-ID: <4HPCL92C89ZyFFl3DQ5Cvc5-WC3qTVsWx8YhI_cX0NM=.3e2a2564-f250-4858-9923-dcf0c36ccc2b@github.com> > `HttpURLConnectionExpectContinueTest` was throwing an error due to port being hardcoded, updated test to let the system decide which port to use. Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision: Update test/jdk/java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14177/files - new: https://git.openjdk.org/jdk/pull/14177/files/49b77cbc..272c8719 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14177&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14177&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/14177.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14177/head:pull/14177 PR: https://git.openjdk.org/jdk/pull/14177 From duke at openjdk.org Thu Jun 8 15:53:05 2023 From: duke at openjdk.org (Darragh Clarke) Date: Thu, 8 Jun 2023 15:53:05 GMT Subject: RFR: 8308336: Test java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java failed: java.net.BindException: Address already in use [v2] In-Reply-To: References:

Message-ID: <_hKoATUpEqVAoha8sXc5sggA4yavlr9zBFWUMyWE9rk=.8cf8c1e4-d9ce-4f5c-b224-76292382ab28@github.com> On Thu, 8 Jun 2023 15:08:22 GMT, Daniel Fuchs wrote: >> test/jdk/java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java line 428: >> >>> 426: URL url = URIBuilder.newBuilder() >>> 427: .scheme("http") >>> 428: .host(InetAddress.getLoopbackAddress()) >> >> This will change the call flow of the test in a slightly subtle way. In the original the "host" is supplied i.e. localhost which should map to the loopback address, and in the change the loopback IP address is being supplied diectly. In terms of equivalence then supplying a host string might be more appropriate: >> .host("localhost") > > No that's precisely what we want to avoid. Because how "localhost" maps to an InetAddress depends on the machine configuration, which is a recipe for intermittent failures. > > I'd suggest: > > URL url = URIBuilder.newBuilder() > .scheme("http") > .localhost() > > (which is actually the same) At a glance there isn't a `.localhost()` only a `.loopback()` is that what you were referring to? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14177#discussion_r1223236970 From dfuchs at openjdk.org Thu Jun 8 16:22:48 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 8 Jun 2023 16:22:48 GMT Subject: RFR: 8308336: Test java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java failed: java.net.BindException: Address already in use [v2] In-Reply-To: <_hKoATUpEqVAoha8sXc5sggA4yavlr9zBFWUMyWE9rk=.8cf8c1e4-d9ce-4f5c-b224-76292382ab28@github.com> References:

<_hKoATUpEqVAoha8sXc5sggA4yavlr9zBFWUMyWE9rk=.8cf8c1e4-d9ce-4f5c-b224-76292382ab28@github.com> Message-ID: On Thu, 8 Jun 2023 15:47:43 GMT, Darragh Clarke wrote: >> No that's precisely what we want to avoid. Because how "localhost" maps to an InetAddress depends on the machine configuration, which is a recipe for intermittent failures. >> >> I'd suggest: >> >> URL url = URIBuilder.newBuilder() >> .scheme("http") >> .localhost() >> >> (which is actually the same) > > At a glance there isn't a `.localhost()` only a `.loopback()` is that what you were referring to? Yes! Sorry - my mistake. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14177#discussion_r1223282455 From duke at openjdk.org Thu Jun 8 16:47:33 2023 From: duke at openjdk.org (Darragh Clarke) Date: Thu, 8 Jun 2023 16:47:33 GMT Subject: RFR: 8308336: Test java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java failed: java.net.BindException: Address already in use [v4] In-Reply-To: References: Message-ID: > `HttpURLConnectionExpectContinueTest` was throwing an error due to port being hardcoded, updated test to let the system decide which port to use. Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision: use loopback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14177/files - new: https://git.openjdk.org/jdk/pull/14177/files/272c8719..9dd40a4c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14177&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14177&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14177.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14177/head:pull/14177 PR: https://git.openjdk.org/jdk/pull/14177 From duke at openjdk.org Thu Jun 8 16:47:36 2023 From: duke at openjdk.org (Darragh Clarke) Date: Thu, 8 Jun 2023 16:47:36 GMT Subject: RFR: 8308336: Test java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java failed: java.net.BindException: Address already in use [v2] In-Reply-To: References:

<_hKoATUpEqVAoha8sXc5sggA4yavlr9zBFWUMyWE9rk=.8cf8c1e4-d9ce-4f5c-b224-76292382ab28@github.com> Message-ID: On Thu, 8 Jun 2023 16:20:02 GMT, Daniel Fuchs wrote: >> At a glance there isn't a `.localhost()` only a `.loopback()` is that what you were referring to? > > Yes! Sorry - my mistake. I pushed that change now and am currently rerunning tests ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14177#discussion_r1223305673 From dfuchs at openjdk.org Thu Jun 8 16:50:49 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 8 Jun 2023 16:50:49 GMT Subject: RFR: 8308336: Test java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java failed: java.net.BindException: Address already in use [v4] In-Reply-To: References:

Message-ID: On Thu, 8 Jun 2023 16:47:33 GMT, Darragh Clarke wrote: >> `HttpURLConnectionExpectContinueTest` was throwing an error due to port being hardcoded, updated test to let the system decide which port to use. > > Darragh Clarke has updated the pull request incrementally with one additional commit since the last revision: > > use loopback LGTM. ------------- Marked as reviewed by dfuchs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14177#pullrequestreview-1470395438 From jjg at openjdk.org Thu Jun 8 17:29:59 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Thu, 8 Jun 2023 17:29:59 GMT Subject: RFR: JDK-8305406: Add @spec tags in java.base/java.* (part 2) [v3] In-Reply-To: <8GpnL45DR-AOzXUpzHoIPsD-PCH9X0D9jpqBczHGVRU=.cdefb63e-84c8-4489-9c98-ce2a00d34e72@github.com> References: <8GpnL45DR-AOzXUpzHoIPsD-PCH9X0D9jpqBczHGVRU=.cdefb63e-84c8-4489-9c98-ce2a00d34e72@github.com> Message-ID: <4aXf_OR_EF_CqqIhswGgOr0dZeHEoJRPRIAIQHtTHD4=.3849ecb7-c0c1-41bf-b81e-b823eb882899@github.com> On Wed, 5 Apr 2023 16:45:06 GMT, Jonathan Gibbons wrote: >> Please review a doc update to add `@spec` into the rest of the files in `java.base` (compared to those in [JDK-8305206](https://bugs.openjdk.org/browse/JDK-8305206) PR #13248) > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > Address review feedback keep-alive comment ------------- PR Comment: https://git.openjdk.org/jdk/pull/13336#issuecomment-1583064392 From jjg at openjdk.org Thu Jun 8 20:18:46 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Thu, 8 Jun 2023 20:18:46 GMT Subject: RFR: JDK-8305406: Add @spec tags in java.base/java.* (part 2) [v3] In-Reply-To: <8GpnL45DR-AOzXUpzHoIPsD-PCH9X0D9jpqBczHGVRU=.cdefb63e-84c8-4489-9c98-ce2a00d34e72@github.com> References: <8GpnL45DR-AOzXUpzHoIPsD-PCH9X0D9jpqBczHGVRU=.cdefb63e-84c8-4489-9c98-ce2a00d34e72@github.com> Message-ID: On Wed, 5 Apr 2023 16:45:06 GMT, Jonathan Gibbons wrote: >> Please review a doc update to add `@spec` into the rest of the files in `java.base` (compared to those in [JDK-8305206](https://bugs.openjdk.org/browse/JDK-8305206) PR #13248) > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > Address review feedback I checked out references to `nist.gov`. I found 7 references to 4 documents: $ grep -r '*.*href=[^ ]*nist.gov' open/src/java.base | grep -o 'nist.gov[^"]*' nist.gov/nistpubs/FIPS/NIST.FIPS.140-2.pdf nist.gov/publications/fips/fips186-3/fips_186-3.pdf nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38F.pdf> nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38F.pdf> nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38F.pdf> nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38F.pdf> Of these 4, 1 shows a page that says the spec has been superseded, and one is effectively a 404 Oops, that's not standard?! Sorry, we cannot find that page. The page you requested cannot be found at this time. I would like to defer these issues to be handled separately, and add `@spec` tags for these pages later, once the appropriate specs have been identified. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13336#issuecomment-1583280716 From jjg at openjdk.org Thu Jun 8 20:49:49 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Thu, 8 Jun 2023 20:49:49 GMT Subject: RFR: JDK-8305406: Add @spec tags in java.base/java.* (part 2) [v3] In-Reply-To: References: <8GpnL45DR-AOzXUpzHoIPsD-PCH9X0D9jpqBczHGVRU=.cdefb63e-84c8-4489-9c98-ce2a00d34e72@github.com> Message-ID: On Thu, 8 Jun 2023 20:16:21 GMT, Jonathan Gibbons wrote: > I checked out references to `nist.gov`. > > I found 7 references to 4 documents: > > ``` > $ grep -r '*.*href=[^ ]*nist.gov' open/src/java.base | grep -o 'nist.gov[^"]*' > nist.gov/nistpubs/FIPS/NIST.FIPS.140-2.pdf > nist.gov/publications/fips/fips186-3/fips_186-3.pdf > nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf > nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38F.pdf> > nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38F.pdf> > nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38F.pdf> > nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38F.pdf> > ``` > > Of these 4, 1 shows a page that says the spec has been superseded, and one is effectively a 404 > > ``` > Oops, that's not standard?! > Sorry, we cannot find that page. > > The page you requested cannot be found at this time. > ``` > > I would like to defer these issues to be handled separately, and add `@spec` tags for these pages later, once the appropriate specs have been identified. Update, the apparent 404 is explained by a scripting error, due to an unquoted attribute value. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13336#issuecomment-1583319302 From jjg at openjdk.org Thu Jun 8 21:20:07 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Thu, 8 Jun 2023 21:20:07 GMT Subject: RFR: JDK-8305406: Add @spec tags in java.base/java.* (part 2) [v4] In-Reply-To: References: Message-ID: > Please review a doc update to add `@spec` into the rest of the files in `java.base` (compared to those in [JDK-8305206](https://bugs.openjdk.org/browse/JDK-8305206) PR #13248) Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Add @spec tags for nist.gov docs - Merge remote-tracking branch 'upstream/master' into 8305406.at-spec-java.base-java-2-javax - Address review feedback - Update src/java.base/share/classes/java/security/cert/X509Certificate.java Co-authored-by: Daniel Jelinski - JDK-8305406: Add @spec tags in java.base/java.* (part 2) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13336/files - new: https://git.openjdk.org/jdk/pull/13336/files/03a70694..1b997359 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13336&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13336&range=02-03 Stats: 554345 lines in 6384 files changed: 454872 ins; 53914 del; 45559 mod Patch: https://git.openjdk.org/jdk/pull/13336.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13336/head:pull/13336 PR: https://git.openjdk.org/jdk/pull/13336 From tsteele at openjdk.org Thu Jun 8 22:09:50 2023 From: tsteele at openjdk.org (Tyler Steele) Date: Thu, 8 Jun 2023 22:09:50 GMT Subject: RFR: 8305906: HttpClient may use incorrect key when finding pooled HTTP/2 connection for IPv6 address [v5] In-Reply-To: References: <3b7IrpY4XC5OYB3SWQ2O1xH_ZUdOn2TDhr1y8h2M2Uw=.0e4b095a-c071-444c-9f67-62b2611e7977@github.com>

Message-ID: <1zCGLhVlv4oX23fJ7OzdsvJMAyxsEzK2D4DSiWISB34=.ed03d3eb-4f87-46d3-950a-585d04bd14c3@github.com> On Wed, 7 Jun 2023 09:43:08 GMT, Jaikiran Pai wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> simplify the keyFor method to accept the entire HttpRequestImpl instance > > Thank you both for the reviews. Thanks for your change @jaikiran! We've seen this issue in my organization occurring in jdk17, and jdk11. It's nice to see that it has been fixed. Do you have any plans to backport it? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13456#issuecomment-1583452832 From serb at openjdk.org Fri Jun 9 04:05:47 2023 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 9 Jun 2023 04:05:47 GMT Subject: RFR: 8304885: Reuse stale data to improve DNS resolver resiliency [v17] In-Reply-To: References:

Message-ID: On Thu, 8 Jun 2023 14:18:10 GMT, Sergey Bylokhov wrote: >> I would like to get preliminary feedback about the provided patch. >> >> Discussion on net-dev@ https://mail.openjdk.org/pipermail/net-dev/2023-March/020682.html >> >> One of the main issue I try to solve is how the cache handle the intermittent DNS server outages due to overloading or network connection. >> >> At the moment this cache can be configured by the application using the following two properties: >> (1) "networkaddress.cache.ttl"(30 sec) - cache policy for successful lookups >> (2) "networkaddress.cache.negative.ttl"(10 sec) - cache policy for negative lookups >> >> The default timeout for positive responses is good enough to "have recent dns-records" and to "minimize the number of requests to the DNS server". >> >> But the cache for the negative responses is problematic. This is a problem I would like to solve. Caching the negative response means that for **10** seconds the application will not be able to connect to the server. >> >> Possible solutions: >> 1. Decreasing timeout "for the negative responses": unfortunately more requests to the server at the moment of "DNS-outage" cause even more issues, since this is not the right moment to load the network/server more. >> 2. Increasing timeout "for the positive responses": this will decrease the chance to get an error, but the cache will start to use stale data longer. >> 3. This proposal: it would be good to ignore the negative response and continue to use the result of the last "successful lookup" until some additional timeout. >> >> The idea is to split the notion of the TTL and the timeout used for the cache. When TTL for the record will expire we should request the new data from the server. If this request goes fine we will update the record, if it fails we will continue to use the cached date until the next sync. >> >> For example, if the new property "networkaddress.cache.extended.ttl" is set to 10 minutes, then we will cache a positive response for 10 minutes but will try to sync it every 30 seconds. If the new property is not set then as before we will cache positive for 30 seconds and then cache the negative response for 10 seconds. >> >> >> RFC 8767 Serving Stale Data to Improve DNS Resiliency: >> https://www.rfc-editor.org/rfc/rfc8767 >> >> Comments about current and other possible implementations: >> * The code intentionally moved to the separate ValidAddresses class, just to make clear that the default configuration, when the new property is not set is not changed much. >> * The refr... > > Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision: > > CSR feedback The CSR is approved, please take a look to the final version. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13285#issuecomment-1583938870 From jpai at openjdk.org Fri Jun 9 09:19:53 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 9 Jun 2023 09:19:53 GMT Subject: RFR: 8305906: HttpClient may use incorrect key when finding pooled HTTP/2 connection for IPv6 address [v5] In-Reply-To: References: <3b7IrpY4XC5OYB3SWQ2O1xH_ZUdOn2TDhr1y8h2M2Uw=.0e4b095a-c071-444c-9f67-62b2611e7977@github.com> Message-ID: On Wed, 7 Jun 2023 06:03:25 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8305906? >> >> As noted in that issue, when IPv6 hosts are involved, the HttpClient on certain occasions can end up caching the connection with a key which doesn't match with the key which is then used in a subsequent request against the same target host. >> >> The commit in this PR now wraps the IPv6 address in a square bracket consistently so that the correct key is used both during storing the connection in the pool and when looking up. >> >> A new jtreg test has been added which reproduces this issue without the fix and verifies the fix. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > simplify the keyFor method to accept the entire HttpRequestImpl instance Hello Tyler, > Do you have any plans to backport it? I haven't been involved in the 11/17 backports in recent times, so I don't have any specific plans to backport this. Having said that, I think this does look like a good candidate for backporting, so if you or anyone has done it before, please do go ahead. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13456#issuecomment-1584247606 From duke at openjdk.org Fri Jun 9 10:17:44 2023 From: duke at openjdk.org (Ferenc Rakoczi) Date: Fri, 9 Jun 2023 10:17:44 GMT Subject: RFR: JDK-8305406: Add @spec tags in java.base/java.* (part 2) [v3] In-Reply-To: References: