Re: [jdk25] RFR: 8359364: java/net/URL/EarlyOrDelayedParsing test fails intermittently
On Fri, 13 Jun 2025 15:01:46 GMT, Daniel Fuchs wrote: > Hi, > > I would like to backport this test-only stabilization fix to the JDK 25. > This will remove some noise from the CI when running on macOS. > > This is a clean backport. Marked as reviewed by alanb (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/25804#pullrequestreview-2925184804
[jdk25] RFR: 8359364: java/net/URL/EarlyOrDelayedParsing test fails intermittently
Hi, I would like to backport this test-only stabilization fix to the JDK 25. This will remove some noise from the CI when running on macOS. This is a clean backport. - Commit messages: - Backport 57cabc6d741c14a8029aec324ba96e8ced4afcbd Changes: https://git.openjdk.org/jdk/pull/25804/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25804&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8359364 Stats: 18 lines in 1 file changed: 17 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25804.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25804/head:pull/25804 PR: https://git.openjdk.org/jdk/pull/25804
Re: RFR: 7116990: (spec) Socket.connect(addr,timeout) not clear if IOException because of TCP timeout [v3]
On Fri, 13 Jun 2025 13:49:55 GMT, Jaikiran Pai wrote: >The timeout values noted in that text are mere examples to convey the detail >that application developers need to >be aware that the timeout they pass to >the connect() method may not influence connection establishment failure >due >to timeout. They aren't exhaustive. I had considered including 21 in that text >too. Alan's suggestion was to >mention "60 or 75 seconds". Right, the objective is to convey to a developer that when specifying a timeout to the connect method, that this timeout may be superseded by an OS's TCP/IP configuration's Connect timeout settings. This is all that needs to be said. There is no need to state any typical values, but if you do then those values need to be factually correct, and for the currently supported platforms 60 seconds is not typical, it's 21, 75, and 128 seconds - PR Review Comment: https://git.openjdk.org/jdk/pull/25690#discussion_r2145194457
Re: RFR: 7116990: (spec) Socket.connect(addr,timeout) not clear if IOException because of TCP timeout [v3]
On Fri, 13 Jun 2025 14:36:21 GMT, Alan Bateman wrote: >> "The timeout values noted in that text are mere examples to convey the >> detail that application developers need to be aware that the timeout they >> pass to the connect() method may not influence connection establishment >> failure due to timeout. They aren't exhaustive. I had considered including >> 21 in that text too. Alan's suggestion was to mention "60 or 75 seconds". " >> >> Right, the objective is to convey to a developer that when specifying a >> timeout to the connect method, that this timeout may be superseded by an >> OS's TCP/IP configuration's Connect timeout settings. >> >> This is all that needs to be said. There is no need to state any typical >> values, but if you do then those values need to be factually correct, and >> for the currently supported platforms 60 seconds is not typical, it's 21, >> 75, and 128 seconds >> >> But if a developer takes guidance from the "typically 60 seconds" statement >> on a Windows environment and set a timeout of 50 seconds, they will get >> IOException is a java.net.ConnectException >> java.net.ConnectException: Operation timed out >> >> as reported in the original bug and as such, defeats the purpose of the >> apiNote > >> This is all that needs to be said. There is no need to state any typical >> values, but if you do then those values need to be factually correct, and >> for the currently supported platforms 60 seconds is not typical, it's 21, >> 75, and 128 seconds > > The proposed wording in the current draft looks okay. It explains to the > reader that establishing a TCP/IP connection is subject to an operating > system timeout. It gives a sense of what that timeout might be, it's not > hours or days, it's tens of seconds. I don't think we should attempt to list > specific timeouts for specific operating system versions and configurations. why are you insisting on specifying 60 seconds? It does not exist on any supported OS platform. There is no need to specify any value in the apiNote, all it does is add misinformation - PR Review Comment: https://git.openjdk.org/jdk/pull/25690#discussion_r2145324159
Re: RFR: 8353113: Peer supported certificate signature algorithms are not being checked with default SunX509 key manager [v4]
On Fri, 6 Jun 2025 21:11:16 GMT, Artur Barashev wrote: >> src/java.base/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java line >> 401: >> >>> 399: continue; >>> 400: } >>> 401: >> >> I think we should also call `CertType.check` here, like in >> `X509KeyManagerImpl`. Since this change is now only selecting certificates >> with algorithms that are not disabled, I think it also makes sense to select >> certificates that have the proper extensions, etc and will not cause >> subsequent certificate chain validation failures. >> >> This means we would have to change the name of the property so that it isn't >> only about disabling constraints checking. Perhaps: >> `jdk.tls.keymanager.disableCertSelectionChecking`. > > Yes, makes sense. Done. - PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2145256449
Re: RFR: 7116990: (spec) Socket.connect(addr,timeout) not clear if IOException because of TCP timeout [v3]
On Fri, 13 Jun 2025 14:14:25 GMT, Mark Sheppard wrote: > This is all that needs to be said. There is no need to state any typical > values, but if you do then those values need to be factually correct, and for > the currently supported platforms 60 seconds is not typical, it's 21, 75, and > 128 seconds The proposed wording in the current draft looks okay. It explains to the reader that establishing a TCP/IP connection is subject to an operating system timeout. It gives a sense of what that timeout might be, it's not hours or days, it's tens of seconds. I don't think we should attempt to list specific timeouts for specific operating system versions and configurations. - PR Review Comment: https://git.openjdk.org/jdk/pull/25690#discussion_r2145237517
Re: RFR: 7116990: (spec) Socket.connect(addr,timeout) not clear if IOException because of TCP timeout [v3]
On Fri, 13 Jun 2025 16:08:43 GMT, Daniel Fuchs wrote: >> why are you insisting on specifying 60 seconds? It does not exist on any >> supported OS platform. There is no need to specify any value in the apiNote, >> all it does is add misinformation > > Maybe we could say: > > > The typical operating system timeout ranges within tens of seconds to minutes. š very good suggestion - PR Review Comment: https://git.openjdk.org/jdk/pull/25690#discussion_r2145459046
Re: RFR: 8353113: Peer supported certificate signature algorithms are not being checked with default SunX509 key manager [v5]
> When the deafult SunX509KeyManagerImpl is being used we are in violation of > TLSv1.3 RFC spec because we ignore peer supported certificate signatures sent > to us in "signature_algorithms"/"signature_algorithms_cert" extensions: > https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.2 > https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.3 > > X509KeyManagerImpl on the other hand includes the algorithms sent by the peer > in "signature_algorithms_cert" extension (or in "signature_algorithms" > extension when "signature_algorithms_cert" extension isn't present) in the > algorithm constraints being checked. > > **SUNX509 KeyManager performance before change** > Benchmark(resume) (tlsVersion) Mode > Cnt Score Error Units > SSLHandshake.doHandshake true TLSv1.2 thrpt 15 19758.012 Ā± > 758.237 ops/s > SSLHandshake.doHandshake true TLS thrpt 15 1861.695 Ā± > 14.681 ops/s > SSLHandshake.doHandshake false TLSv1.2 thrpt 15 **1186.962** Ā± > 12.085 ops/s > SSLHandshake.doHandshake false TLS thrpt 15 **1056.288** Ā± > 7.197 ops/s > > **SUNX509 KeyManager performance after change** > Benchmark (resume) (tlsVersion) Mode Cnt Score > Error Units > SSLHandshake.doHandshake true TLSv1.2 thrpt 15 20954.399 Ā± > 260.817 ops/s > SSLHandshake.doHandshake true TLS thrpt 15 1813.401 Ā± > 13.917 ops/s > SSLHandshake.doHandshake false TLSv1.2 thrpt 15 **1158.190** Ā± > 6.023 ops/s > SSLHandshake.doHandshake false TLS thrpt 15 **1012.988** Ā± > 10.943 ops/s Artur Barashev 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 19 additional commits since the last revision: - Support certificate checks in SunX509 key manager - Address some review comments - Merge branch 'master' into JDK-8353113 - Make the test run on TLSv1.3 - Make sure the exception happens during KeyManager's algorithm check - Add PeerConstraintsCheck unit test - Add unit test - Code refactoring - Fix open unit tests - Adding a system property to skip the constraints checking. Remove SunX509c. - ... and 9 more: https://git.openjdk.org/jdk/compare/5479addb...448442e9 - Changes: - all: https://git.openjdk.org/jdk/pull/25016/files - new: https://git.openjdk.org/jdk/pull/25016/files/451e1efd..448442e9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25016&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25016&range=03-04 Stats: 228571 lines in 4300 files changed: 142799 ins; 58830 del; 26942 mod Patch: https://git.openjdk.org/jdk/pull/25016.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25016/head:pull/25016 PR: https://git.openjdk.org/jdk/pull/25016
Re: RFR: 8351983: HttpCookie Parser Incorrectly Handles Cookies with Expires Attribute [v6]
> Hi, > > This is a fix to j.n.HttpCookie (which has a doc/spec change). So, I'm > targeting it to 26. > We currently do not obey the rule in RFC 6265 that says if both Max-Age and > Expires attributes > are present in a cookie, the Max-Age should take precedence. > > Thanks > Michael Michael McMahon has updated the pull request incrementally with one additional commit since the last revision: impl update - Changes: - all: https://git.openjdk.org/jdk/pull/25636/files - new: https://git.openjdk.org/jdk/pull/25636/files/9a495d7f..b2211311 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25636&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25636&range=04-05 Stats: 39 lines in 1 file changed: 19 ins; 15 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/25636.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25636/head:pull/25636 PR: https://git.openjdk.org/jdk/pull/25636
Re: RFR: 7116990: (spec) Socket.connect(addr,timeout) not clear if IOException because of TCP timeout [v3]
On Fri, 13 Jun 2025 15:20:47 GMT, Mark Sheppard wrote: >>> This is all that needs to be said. There is no need to state any typical >>> values, but if you do then those values need to be factually correct, and >>> for the currently supported platforms 60 seconds is not typical, it's 21, >>> 75, and 128 seconds >> >> The proposed wording in the current draft looks okay. It explains to the >> reader that establishing a TCP/IP connection is subject to an operating >> system timeout. It gives a sense of what that timeout might be, it's not >> hours or days, it's tens of seconds. I don't think we should attempt to list >> specific timeouts for specific operating system versions and configurations. > > why are you insisting on specifying 60 seconds? It does not exist on any > supported OS platform. There is no need to specify any value in the apiNote, > all it does is add misinformation Maybe we could say: The typical operating system timeout ranges within tens of seconds to minutes. - PR Review Comment: https://git.openjdk.org/jdk/pull/25690#discussion_r2145436929
[jdk25] Integrated: 8359364: java/net/URL/EarlyOrDelayedParsing test fails intermittently
On Fri, 13 Jun 2025 15:01:46 GMT, Daniel Fuchs wrote: > Hi, > > I would like to backport this test-only stabilization fix to the JDK 25. > This will remove some noise from the CI when running on macOS. > > This is a clean backport. This pull request has now been integrated. Changeset: 41117308 Author:Daniel Fuchs URL: https://git.openjdk.org/jdk/commit/41117308450a09df2de3ba608612b1ec67988761 Stats: 18 lines in 1 file changed: 17 ins; 0 del; 1 mod 8359364: java/net/URL/EarlyOrDelayedParsing test fails intermittently Reviewed-by: alanb Backport-of: 57cabc6d741c14a8029aec324ba96e8ced4afcbd - PR: https://git.openjdk.org/jdk/pull/25804
Re: RFR: 8359364: java/net/URL/EarlyOrDelayedParsing test fails intermittently [v2]
On Thu, 12 Jun 2025 18:52:12 GMT, Daniel Fuchs wrote: >> Like >> [java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java](https://git.openjdk.org/jdk/pull/25692), >> the test java/net/URL/EarlyOrDelayedParsing doesn't expect proxies, and may >> fail if a proxy is selected. >> >> The test sets system properties and runs in otrhervm. The fix is to set up a >> default ProxySelector that will always return NO_PROXY. > > Daniel Fuchs has updated the pull request incrementally with one additional > commit since the last revision: > > Copyright update Marked as reviewed by alanb (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/25783#pullrequestreview-2924763153
Re: RFR: 8359364: java/net/URL/EarlyOrDelayedParsing test fails intermittently [v2]
On Thu, 12 Jun 2025 18:52:12 GMT, Daniel Fuchs wrote: >> Like >> [java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java](https://git.openjdk.org/jdk/pull/25692), >> the test java/net/URL/EarlyOrDelayedParsing doesn't expect proxies, and may >> fail if a proxy is selected. >> >> The test sets system properties and runs in otrhervm. The fix is to set up a >> default ProxySelector that will always return NO_PROXY. > > Daniel Fuchs has updated the pull request incrementally with one additional > commit since the last revision: > > Copyright update This looks fine to me. Although there's a test `@run` which is not `othervm`, setting this default ProxySelector (and not resetting it back) should be fine since `jdk.net.url.delayParsing` by default is `false` and we don't set the ProxySelector in those cases. - Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25783#pullrequestreview-2924775768
Integrated: 8359364: java/net/URL/EarlyOrDelayedParsing test fails intermittently
On Thu, 12 Jun 2025 16:02:51 GMT, Daniel Fuchs wrote: > Like > [java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java](https://git.openjdk.org/jdk/pull/25692), > the test java/net/URL/EarlyOrDelayedParsing doesn't expect proxies, and may > fail if a proxy is selected. > > The test sets system properties and runs in otrhervm. The fix is to set up a > default ProxySelector that will always return NO_PROXY. This pull request has now been integrated. Changeset: 57cabc6d Author:Daniel Fuchs URL: https://git.openjdk.org/jdk/commit/57cabc6d741c14a8029aec324ba96e8ced4afcbd Stats: 18 lines in 1 file changed: 17 ins; 0 del; 1 mod 8359364: java/net/URL/EarlyOrDelayedParsing test fails intermittently Reviewed-by: vyazici, syan, alanb - PR: https://git.openjdk.org/jdk/pull/25783
Re: RFR: 7116990: (spec) Socket.connect(addr,timeout) not clear if IOException because of TCP timeout [v3]
On Fri, 13 Jun 2025 09:16:39 GMT, Mark Sheppard wrote: > Also first sentence need minor refinement changing connection timeout to > connect timeout > > connection timeout is when the connection is established I haven't previously seen connection timeout term being used to mean a timeout (for the connection?) after the connection has been established. I'll however change that text to say "connect timeout" shortly. > I don't understand why you are persisting with 60 seconds, when the original > reporter shows its a default of 21 seconds on Windows, which I have also > confirmed and that windows requires. 21 seconds is a very much not typically > 60 seconds The timeout values noted in that text are mere examples to convey the detail that application developers need to be aware that the `timeout` they pass to the `connect()` method may not influence connection establishment failure due to timeout. They aren't exhaustive. I had considered including 21 in that text too. Alan's suggestion was to mention "60 or 75 seconds". - PR Review Comment: https://git.openjdk.org/jdk/pull/25690#discussion_r2145148121
Re: RFR: 8351983: HttpCookie Parser Incorrectly Handles Cookies with Expires Attribute [v5]
On Thu, 12 Jun 2025 18:20:58 GMT, Volkan Yazici wrote: > @Michael-Mc-Mahon, instead of making an exception for `max-age` and > `expires`, and removing them from `assignors`, can't we convert the type of > `assignors` from `Map` to `List` and add `max-age` & `expires` entries at the > end? Just converting from Map to List wouldn't be enough. The problem is that both attribute types need to be handled together. You could change the attribute name recognition to some kind of pattern match to recognise either of them. Then you need to know which of them was set and what their values were. Maybe, I could at least use the assignor pattern to recognise the two attributes and limit the special code to just actioning the values. I'll take a look at that now. - PR Review Comment: https://git.openjdk.org/jdk/pull/25636#discussion_r2145264788
Re: RFR: 7116990: (spec) Socket.connect(addr,timeout) not clear if IOException because of TCP timeout [v3]
On Fri, 13 Jun 2025 07:12:17 GMT, Jaikiran Pai wrote: >> Can I please get a review of this doc-only change which proposes to add a >> `@apiNote` to the `Socket.connect(SocketAddress endpoint, int timeout)` >> method? This addresses https://bugs.openjdk.org/browse/JDK-7116990. >> >> As noted in that issue, users can find it surprising that when the >> `Socket.connect(...)` method is called with a `timeout` value, then if that >> timeout value happens to be greater than the connect timeout that operating >> systems typically impose, then a `IOException` gets thrown instead of the >> `SocketTimeoutException`. The change in this PR proposes to add a `@apiNote` >> which explains this current behaviour. >> >> If this requires a CSR, I'll open one once we settle on the proposed text. > > Jaikiran Pai has updated the pull request incrementally with one additional > commit since the last revision: > > improve text Marked as reviewed by dfuchs (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/25690#pullrequestreview-2923879325
Re: RFR: 8340182: Java HttpClient does not follow default retry limit of 3 retries [v6]
On Thu, 12 Jun 2025 17:52:51 GMT, p-nima wrote: >> The AuthenticationFilter did not respect the default retry limit of 3 >> retries in case of invalid credentials supplied. >> >> This PR helps to resolve the bug and tests it with default and updated retry >> limit set via `jdk.httpclient.auth.retrylimit=1`. >> >> The test is green with tiers 1, 2, 3 and the test is stable. > > p-nima has updated the pull request incrementally with one additional commit > since the last revision: > > update copyright @p-nima Your change (at version 8803830b39f03ef60e2e96a33773bf0fcd0e70e7) is now ready to be sponsored by a Committer. - PR Comment: https://git.openjdk.org/jdk/pull/25490#issuecomment-2969602241
Re: RFR: 8359402: TesCloseDescriptors.java should throw SkippedException when there is no lsof/sctp
On Fri, 13 Jun 2025 06:36:19 GMT, SendaoYan wrote: > Hi all, > > Test com/sun/nio/sctp/SctpChannel/CloseDescriptors.java should throw > jtreg.SkippedException when there is no lsof command or there is no SCTP in > test machine. > Before this PR, this test report Execution successful when there is no SCTP. > > > -- > TEST: com/sun/nio/sctp/SctpChannel/CloseDescriptors.java > TEST RESULT: Passed. Execution successful > -- > > > After this PR, it will report `jtreg.SkippedException` when there is no SCTP > > > -- > TEST: com/sun/nio/sctp/SctpChannel/CloseDescriptors.java > TEST RESULT: Passed. Skipped: jtreg.SkippedException: SCTP protocol is not > supported > -- > > > Change has been verified locally, test-fix only, no risk. Marked as reviewed by vyazici (Committer). test/jdk/com/sun/nio/sctp/SctpChannel/CloseDescriptors.java line 30: > 28: * @requires (os.family == "linux") > 29: * @library /test/lib > 30: * @build jtreg.SkippedException I've totally missed that `jtreg.SkippedException` should indeed be added to `@build`. Now I can land a PR touching thousands of test files using `SE`. š (No, I won't. š ) - PR Review: https://git.openjdk.org/jdk/pull/25790#pullrequestreview-2923605868 PR Review Comment: https://git.openjdk.org/jdk/pull/25790#discussion_r2144328418
Re: RFR: 7116990: (spec) Socket.connect(addr,timeout) not clear if IOException because of TCP timeout [v3]
On Thu, 12 Jun 2025 10:19:21 GMT, Mark Sheppard wrote:
>> Looking at this on the 3 main OS platforms (Windows, OL and macOS) and
>> running a simple test to trigger a connect timeout then finding are
>>
>> macOS the connect timeout is 75 seconds as this is derived from 4.3 BSD
>>
>> If OL linux has a syn retries set to 6 and an RTO == 1 sec then itās connect
>> timeout is 130 seconds approx
>> Thatās initial syn timeout of 1 seconds and then 6 retries totalling 127
>> seconds
>>
>> Windows by default connect timeout is 21 seconds
>> RTT == 3 seconds and two connect retries
>> Initial syn timeout 3 seconds + 2 retries at 6 and 12 seconds == 21 seconds
>
> FWIW an possible alternative wording
>
> Establishing a TCP/IP connection is subject to a connect timeout, determined
> by configuration settings
> of the operating system, for example the number of connect retries together
> with a TCP/IP implementationās back off strategy. Thus, TCP/IP Connect
> timeout values can vary across operating system, for example 75 seconds on
> macOS, with a default value of 21 seconds on Windows system. As such, the
> operating system TCP/IP Connect timeout may expire before that specified to
> the connect method. If the operating system Connect timeout expires
> before the {@code timeout} specified to this method then an {@code
> IOException} is thrown. The {@code timeout}
> specified to this method is typically a timeout value that is shorter than
> the operating system timeout.
Hello Mark, I discussed this with Alan and based on those discussions I have
now reworded that sentence to make it clear that 60 second isn't the only
typical timeout and at the same time keep the text concise.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/25690#discussion_r2144350812
Re: RFR: 7116990: (spec) Socket.connect(addr,timeout) not clear if IOException because of TCP timeout [v3]
> Can I please get a review of this doc-only change which proposes to add a > `@apiNote` to the `Socket.connect(SocketAddress endpoint, int timeout)` > method? This addresses https://bugs.openjdk.org/browse/JDK-7116990. > > As noted in that issue, users can find it surprising that when the > `Socket.connect(...)` method is called with a `timeout` value, then if that > timeout value happens to be greater than the connect timeout that operating > systems typically impose, then a `IOException` gets thrown instead of the > `SocketTimeoutException`. The change in this PR proposes to add a `@apiNote` > which explains this current behaviour. > > If this requires a CSR, I'll open one once we settle on the proposed text. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: improve text - Changes: - all: https://git.openjdk.org/jdk/pull/25690/files - new: https://git.openjdk.org/jdk/pull/25690/files/d6978f0d..124e0970 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25690&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25690&range=01-02 Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/25690.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25690/head:pull/25690 PR: https://git.openjdk.org/jdk/pull/25690
Re: RFR: 8359223: HttpClient: Remove leftovers from the SecurityManager cleanup [v2]
> Removes following files added in > [JDK-8235459](https://bugs.openjdk.org/browse/JDK-8235459) and are forgotten > to be removed during the `SecurityManager`-removal > ([JDK-8344228](https://bugs.openjdk.org/browse/JDK-8344228)): > > > test/jdk/java/net/httpclient/FilePublisher/FilePublisherPermsTest.java > test/jdk/java/net/httpclient/FilePublisher/SecureZipFSProvider.java Volkan Yazici 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 three additional commits since the last revision: - Move `FilePublisherTest` one level up - Merge remote-tracking branch 'upstream/master' into hcSmFollowUp - Remove leftover tests from the SecurityManager cleanup - Changes: - all: https://git.openjdk.org/jdk/pull/25747/files - new: https://git.openjdk.org/jdk/pull/25747/files/4a911af9..8eb99336 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25747&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25747&range=00-01 Stats: 10935 lines in 147 files changed: 8513 ins; 1685 del; 737 mod Patch: https://git.openjdk.org/jdk/pull/25747.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25747/head:pull/25747 PR: https://git.openjdk.org/jdk/pull/25747
Re: RFR: 7116990: (spec) Socket.connect(addr,timeout) not clear if IOException because of TCP timeout [v3]
On Fri, 13 Jun 2025 07:08:58 GMT, Jaikiran Pai wrote:
>> FWIW an possible alternative wording
>>
>> Establishing a TCP/IP connection is subject to a connect timeout, determined
>> by configuration settings
>> of the operating system, for example the number of connect retries together
>> with a TCP/IP implementationās back off strategy. Thus, TCP/IP Connect
>> timeout values can vary across operating system, for example 75 seconds on
>> macOS, with a default value of 21 seconds on Windows system. As such, the
>> operating system TCP/IP Connect timeout may expire before that specified to
>> the connect method. If the operating system Connect timeout expires
>> before the {@code timeout} specified to this method then an {@code
>> IOException} is thrown. The {@code timeout}
>> specified to this method is typically a timeout value that is shorter than
>> the operating system timeout.
>
> Hello Mark, I discussed this with Alan and based on those discussions I have
> now reworded that sentence to make it clear that 60 second isn't the only
> typical timeout and at the same time keep the text concise.
Hi JP,
I don't understand why you are persisting with 60 seconds, when the original
reporter shows its a default of 21 seconds on Windows, which I have also
confirmed and that windows requires TcpMaxConnectRetransmissions to adjusted to
enable a higher connect timeout. 21 seconds is a very much not typically 60
seconds
I have given feedback as a developer of the type of detail and wording which I
would find useful. The "typically" statement is inaccurate and misleading
Also first sentence need minor refinement changing connection timeout to
connect timeout
connection timeout is when the connection is established
Thus should read:
Establishing a TCP/IP connection is subject to connect timeout settings in the
operating system.
I think it is important to have some accurate details in this wording, as such
documentation is taken a de facto standard and will persist for aeons
-
PR Review Comment: https://git.openjdk.org/jdk/pull/25690#discussion_r2144570845
Integrated: 8340182: Java HttpClient does not follow default retry limit of 3 retries
On Wed, 28 May 2025 11:26:17 GMT, p-nima wrote: > The AuthenticationFilter did not respect the default retry limit of 3 retries > in case of invalid credentials supplied. > > This PR helps to resolve the bug and tests it with default and updated retry > limit set via `jdk.httpclient.auth.retrylimit=1`. > > The test is green with tiers 1, 2, 3 and the test is stable. This pull request has now been integrated. Changeset: ead4529c Author:Prateek Nima Committer: Daniel Fuchs URL: https://git.openjdk.org/jdk/commit/ead4529c9219009fc4224e52e9ac4af5055e7137 Stats: 136 lines in 2 files changed: 135 ins; 0 del; 1 mod 8340182: Java HttpClient does not follow default retry limit of 3 retries Reviewed-by: dfuchs - PR: https://git.openjdk.org/jdk/pull/25490
java.net.URLConnection.getContent()
java.net.URLConnection has public Object getContent(); It uses the desktop module to find handlers for image and audio data Briefly, the desktop module Ā Ā Ā "provides java.net.ContentHandlerFactory with Ā Ā Ā sun.awt.www.content.MultimediaContentHandlers;" That knows about several audio and image mime types. And URLConnection passes a mimetype string to the ContentHandlerFactory If it is one of the mimetypes known to the desktop provider URLConnection gets returned one of URLImageSource java.awt.Image java.applet.AudioClip But the return type of getContent() is just java.lang.Object and nothing is specified. How does anything use this API ? The reason this comes up is that when removing the Applet API, this needs to transition to something other than AudioClip - but who would notice if it got back null instead ? Or just a byte[] of the raw data ? Or something else ? Is this API actually used ? Or useful ? -phil
