8368528: HttpClient.Builder.connectTimeout should accept arbitrarily large values

[vy]

Introduce necessary fixes to address exceptions thrown when excessive Durations are provided to Duration-accepting HttpClient public APIs.

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue

Issue

• JDK-8368528: HttpClient.Builder.connectTimeout should accept arbitrarily large values (Bug - P4)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/27973/head:pull/27973
$ git checkout pull/27973

Update a local copy of the PR:
$ git checkout pull/27973
$ git pull https://git.openjdk.org/jdk.git pull/27973/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 27973

View PR using the GUI difftool:
$ git pr show -t 27973

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/27973.diff

Using Webrev

Link to Webrev Comment

[vy]

Addresses following failures:

Caused by: java.lang.ArithmeticException: long overflow
   at java.base/java.lang.Math.multiplyExact(Math.java:1036)
   at java.base/java.lang.Math.multiplyExact(Math.java:1012)
   at java.base/java.time.Duration.toMillis(Duration.java:1243)
   at java.net.http/jdk.internal.net.http.HttpQuicConnection$H3QuicConnectionImpl.connectAsync(HttpQuicConnection.java:509)

[bridgekeeper]

👋 Welcome back vyazici! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[vy]

Addresses two following failures:

Caused by: java.time.DateTimeException: Instant exceeds minimum or maximum instant
   at java.base/java.time.Instant.plusSeconds(Instant.java:883)
   at java.base/java.time.Instant.plus(Instant.java:856)
   at java.base/java.time.Instant.plus(Instant.java:209)
   at java.base/java.time.Duration.addTo(Duration.java:1120)
   at java.base/java.time.Instant.plus(Instant.java:788)
   at java.net.http/jdk.internal.net.http.common.Deadline.plus(Deadline.java:177)

Caused by: java.lang.ArithmeticException: long overflow
   at java.base/java.lang.Math.multiplyExact(Math.java:1036)
   at java.base/java.time.Instant.millisUntil(Instant.java:1207)
   at java.base/java.time.Instant.until(Instant.java:1153)
   at java.net.http/jdk.internal.net.http.common.Deadline.until(Deadline.java:200)

[openjdk]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[openjdk]

@vy The following label will be automatically applied to this pull request:

• net

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[vy]

The reproduction by the reporter provides 3 Duration values triggering failures. Above two is sufficient to reproduce all 3 exceptions shared earlier:

1. plus(Deadline.java:177)
2. until(Deadline.java:200)
3. connectAsync(HttpQuicConnection.java:509)

[mlbridge]

Webrevs

• 00: Full (c2179b8a)

[pavelrappo]

We might soon have saturating addition functionality in java.time.Instant; see: #27549

I note that jdk.internal.net.http.common.Deadline also wants to have saturating subtraction, and I wonder if that's really needed. It seems that the two usages of the minus method in the codebase can be reimplemented alternatively. In which case Deadline could delete minus.

Furthermore, if there's no need for saturating subtraction, do we need the Deadline class? What does it provide, that Instant does not?

[vy]

We might soon have saturating addition functionality in java.time.Instant; see: #27549

Great tip! 💯 I will hold this PR until #27549 gets merged, and use Instant::plusSaturated in Deadline::plus* and ::minus methods.

I note that jdk.internal.net.http.common.Deadline also wants to have saturating subtraction, and I wonder if that's really needed. It seems that the two usages of the minus method in the codebase can be reimplemented alternatively. In which case Deadline could delete minus.

I also have my reservations regarding the rich, yet seldom used API surface of Deadline. But revamping it is out of the scope of this work.

Furthermore, if there's no need for saturating subtraction, do we need the Deadline class? What does it provide, that Instant does not?

In short, Instant is not necessarily generated using a monotonically-increasing InstantSource. Deadline is introduced to avoid that ambiguity and guaranteed to be always monotonically-increasing. See this conversation for details.

[pavelrappo]

We might soon have saturating addition functionality in java.time.Instant; see: #27549

Great tip! 💯 I will hold this PR until #27549 gets merged, and use Instant::plusSaturated in Deadline::plus* and ::minus methods.

One problem for this PR is that the proposed Instant functionality in that PR will only work with Duration not TemporalAmount. Another problem is that you cannot implement saturating subtraction based on saturating addition here. If you are thinking along these lines, then it will fail if amountToSubtract is the minimum value for Duration:

deadline.plus(amountToSubtract.negated())

Now, I understand that in your case you will never have negative duration, let alone such extremely negative one. But it would still be good to be robust, especially if it also involves less code.

Deadline.minus seems to be used twice. Both times it is used for a comparison like this:

t1 - dt < t0

To avoid subtraction, rearrange the terms. Different rearrangements enable different options, but either option is fine:

• t1 - t0 < dt (compare durations using Instant.until/Duration.between)
• t1 < t0 + dt (compare instants using future Instant.plusSaturating)

I note that jdk.internal.net.http.common.Deadline also wants to have saturating subtraction, and I wonder if that's really needed. It seems that the two usages of the minus method in the codebase can be reimplemented alternatively. In which case Deadline could delete minus.

I also have my reservations regarding the rich, yet seldom used API surface of Deadline. But revamping it is out of the scope of this work.

Furthermore, if there's no need for saturating subtraction, do we need the Deadline class? What does it provide, that Instant does not?

In short, Instant is not necessarily generated using a monotonically-increasing InstantSource. Deadline is introduced to avoid that ambiguity and guaranteed to be always monotonically-increasing. See this conversation for details.

Okay, so you want your source of ticks to be exclusive and monotonic, neither of which could be guaranteed without introducing a few specialised types. Got it.