From egahlin at openjdk.org  Sun Jun  1 13:12:00 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Sun, 1 Jun 2025 13:12:00 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events
In-Reply-To: <Pb7W24qpASuvcdw8ElmNW-RubVkddYTqvzDQPGCvvrw=.6bec04d0-5dc0-493f-8ebd-d1595f3c4946@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <Pb7W24qpASuvcdw8ElmNW-RubVkddYTqvzDQPGCvvrw=.6bec04d0-5dc0-493f-8ebd-d1595f3c4946@github.com>
Message-ID: <KxlQQTym19WULE3miG6oD_hV6Zh4mSlw1zRHCswk0Eg=.82623696-1fac-4294-a187-07956c424814@github.com>

On Sat, 31 May 2025 20:13:01 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Could I have review of an enhancement that adds rate-limited sampling to Java event, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
>> 
>> Testing: test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> src/jdk.jfr/share/classes/jdk/jfr/Throttle.java line 39:
> 
>> 37:  * example, {@code "100/s"}).
>> 38:  * <p>
>> 39:  * If the event class annotated with {@code Throttle} are filtered by other
> 
> "is filtered"

Will fix

> src/jdk.jfr/share/classes/jdk/jfr/internal/ClassInspector.java line 148:
> 
>> 146:             return true;
>> 147:         }
>> 148:         if (superClass != null) {
> 
> Does this also need to search superClass's super?

The annotation is inherited so  superClass's super will be included.

> src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 256:
> 
>> 254:             // }
>> 255:             getEventConfiguration(codeBuilder);
>> 256:             codeBuilder.aload(0);
> 
> Can issue a dup() here if you want to avoid the second aload(0).

I don't think it will work because the result of the first getField (startTime) will be on the stack, when we issue the next getField (duration).

> src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 257:
> 
>> 255:             getEventConfiguration(codeBuilder);
>> 256:             codeBuilder.aload(0);
>> 257:             getfield(codeBuilder, eventClassDesc, ImplicitFields.FIELD_START_TIME);
> 
> In native,we use the endTime for duration events? Is there a need to synchronize the two?

The duration is added later, in throttle. There is no this.endTime field to read here.

> src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 590:
> 
>> 588:     private void setDuration(CodeBuilder codeBuilder, Consumer<CodeBuilder> expression) {
>> 589:         codeBuilder.aload(0);
>> 590:         expression.accept(codeBuilder);
> 
> dont know what expression.accept() does, but does it really consume the this pointer? I see its pushed again (aload(0)) if its throttled below?

We need "this" on stack before the arguments are loaded in expression which is to be used at the end of the method by putfield

> src/jdk.jfr/share/classes/jdk/jfr/internal/event/EventConfiguration.java line 59:
> 
>> 57:     // static boolean shouldThrottleCommit(long timestamp)
>> 58:     public boolean shouldThrottleCommit(long timestamp) {
>> 59:         return throttler.sample(timestamp);
> 
> Can we assert on isEnabled?

Between the time of the enabled() check and this method, the state may change, so it could lead to false positives in testing.

> src/jdk.jfr/share/classes/jdk/jfr/internal/settings/Throttler.java line 62:
> 
>> 60:     // Not synchronized in fast path, but uses volatile reads.
>> 61:     public boolean sample(long ticks) {
>> 62:         if (disabled) {
> 
> This volatile load is somewhat disappointing. Do you think it is needed? What happens if it is read without happens-before? It just creates an event that will most likely get discarded by the recorder engine on reset (if its set on setting update). If it's set to disabled, then the recorder engine has most likely stopped already, so the event will be discarded. Event settings are set with no visibility guarantees as to exact when they apply, so it should not really matter when it goes to disabled.

I think we can skip it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2119136217
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2119135926
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2119135820
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2119134807
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2119134400
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2119132932
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2119136976

From mgronlun at openjdk.org  Sun Jun  1 19:05:53 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 1 Jun 2025 19:05:53 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <e6_OvsZFxNg64ypSkFBoDjvls1ijTSSdXgWS0Xx0VTU=.0a41a851-5870-47fd-866b-e52414125574@github.com>

On Fri, 30 May 2025 22:30:25 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of an enhancement that adds rate-limited sampling to Java event, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

src/jdk.jfr/share/classes/jdk/jfr/internal/settings/Throttler.java line 130:

> 128:     }
> 129: 
> 130:     private long amortizedDebt(ThrottlerWindow expired) {

amortizeDept (in the present) - like this is the value we will be using to amortize (in the future)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2119457164

From mgronlun at openjdk.org  Sun Jun  1 19:10:51 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 1 Jun 2025 19:10:51 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <FEIE0-ddPBZ6gsmBek0zuu2lPmoaQLWsz8h-BfMk5fM=.17498c82-6f01-46f6-b22d-1d63a2b011a2@github.com>

On Fri, 30 May 2025 22:30:25 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of an enhancement that adds rate-limited sampling to Java event, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

src/jdk.jfr/share/classes/jdk/jfr/internal/settings/Throttler.java line 148:

> 146:         return nextGeometric(adjustBoundary(projectProbability), randomGenerator.nextDouble());
> 147:     }
> 148:      double projectPopulationSize(ThrottlerWindow expired) {

not private?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2119459623

From mgronlun at openjdk.org  Sun Jun  1 19:18:54 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 1 Jun 2025 19:18:54 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <RlRa2RB5v1Qm646gChkE1yYwCT8WcKm10nqp2sdgMVk=.071fc361-fe53-43aa-9eeb-9ae1d62388e4@github.com>

On Fri, 30 May 2025 22:30:25 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of an enhancement that adds rate-limited sampling to Java event, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

src/jdk.jfr/share/classes/jdk/jfr/internal/settings/Throttler.java line 142:

> 140:     private long deriveSamplingInterval(double sampleSize, ThrottlerWindow expired) {
> 141:         double populationSize = projectPopulationSize(expired);
> 142:         if (adjustBoundary(populationSize) <= adjustBoundary(sampleSize)) {

Do you need all these adjustBoundary() calls? It only checks if a double value is 0 or 1. Population and sample sizes will be much larger.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2119471003

From mgronlun at openjdk.org  Sun Jun  1 19:25:51 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 1 Jun 2025 19:25:51 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <mldyqnpMWfzVdJXfKIrPjo4IUM4GBepsN-oCqS8ycfU=.9704ab37-e319-4289-ad1f-9e0dde646602@github.com>

On Fri, 30 May 2025 22:30:25 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of an enhancement that adds rate-limited sampling to Java event, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

src/jdk.jfr/share/classes/jdk/jfr/internal/settings/ThrottlerWindow.java line 49:

> 47:         measuredPopulationSize.set(0);
> 48:         endTicks = JVM.counterTime() +
> 49:         JVMSupport.nanosToTicks(1_000_000L * parameters.windowDurationMillis);

indent to make it clear it assigns.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2119475462

From egahlin at openjdk.org  Sun Jun  1 20:56:50 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Sun, 1 Jun 2025 20:56:50 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v2]
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <sdD_sCKqgIH47ozZr_JLBa38whUshwsAYpPhlb8YVbQ=.4dc670bc-2efd-4d73-a92b-982d40483d55@github.com>

> Could I have review of an enhancement that adds rate-limited sampling to Java event, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:

  Some reviewer feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25559/files
  - new: https://git.openjdk.org/jdk/pull/25559/files/73943e7a..d0097506

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25559&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25559&range=00-01

  Stats: 10 lines in 3 files changed: 1 ins; 1 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/25559.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25559/head:pull/25559

PR: https://git.openjdk.org/jdk/pull/25559

From egahlin at openjdk.org  Sun Jun  1 21:10:52 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Sun, 1 Jun 2025 21:10:52 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v2]
In-Reply-To: <o_6aEWGcuMA1YtNY7EhcwJalOJpRE5kuF1KxVLnJiuM=.ae6ae3bb-162b-4776-b2a9-e0c4dcb0d482@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <o_6aEWGcuMA1YtNY7EhcwJalOJpRE5kuF1KxVLnJiuM=.ae6ae3bb-162b-4776-b2a9-e0c4dcb0d482@github.com>
Message-ID: <alGBSpA2d3llrqNVFIf8r5jDHTM517LXhzVO_r5XK3E=.28742e7a-e306-46d4-9533-683fdb8e80a4@github.com>

On Sat, 31 May 2025 21:20:17 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Some reviewer feedback
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 261:
> 
>> 259:             getfield(codeBuilder, eventClassDesc, ImplicitFields.FIELD_DURATION);
>> 260:             Bytecode.invokevirtual(codeBuilder, TYPE_EVENT_CONFIGURATION, METHOD_THROTTLE);
>> 261:             int result = codeBuilder.allocateLocal(TypeKind.LONG);
> 
> Do we really need to store the result in a local? Can't we just dup it on the expression stack and store it directly into the field after another aload, or dup? Perhaps dup twice to then issue the mask operation?

We could do an aload(0) at the beginning, before getEventConfiguration(codeBuilder), to have "this" for putfield(duration) later, but then we would need to do a getfield(this.duration) to have it on the stack for the mask.

We can't do a dup() on duration because we need "this" on the stack to store it in this.duration. I thought using a local variable would be faster than accessing this.duration. It also reduces the chance of the value being changed by another thread.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2119593028

From vyazici at openjdk.org  Mon Jun  2 09:02:56 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 2 Jun 2025 09:02:56 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v2]
In-Reply-To: <sdD_sCKqgIH47ozZr_JLBa38whUshwsAYpPhlb8YVbQ=.4dc670bc-2efd-4d73-a92b-982d40483d55@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <sdD_sCKqgIH47ozZr_JLBa38whUshwsAYpPhlb8YVbQ=.4dc670bc-2efd-4d73-a92b-982d40483d55@github.com>
Message-ID: <uXeoMZ7n-Nb_hygLGtFpWwGR8W8ooZmHvVqBQmdzQWo=.22bb4db5-88f3-4b2a-a348-5162d84d0427@github.com>

On Sun, 1 Jun 2025 20:56:50 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of an enhancement that adds rate-limited sampling to Java event, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
>> 
>> Testing: test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Some reviewer feedback

src/jdk.jfr/share/classes/jdk/jfr/internal/settings/Throttler.java line 30:

> 28: import java.util.concurrent.locks.ReentrantLock;
> 29: import jdk.jfr.internal.PlatformEventType;
> 30: public final class Throttler {

**Disclaimer:** I am a passer-by and I don't possess a deep JFR experience.

Throttling (aka. rate limiting) is a pretty much non-trivial functionality. Shall we

- Revamp the JavaDoc and document the used algorithm?
- Have a dedicated test for `Throttler`? (I see that the newly added `TestThrottle` tests `@Throttle`, hence it also covers `Throttler`. Though there I could not see any verification based on the time[stamp] of events.)

### References

- Resilience4j:
  - [AtomicRateLimiter](https://github.com/resilience4j/resilience4j/blob/master/resilience4j-ratelimiter/src/main/java/io/github/resilience4j/ratelimiter/internal/AtomicRateLimiter.java)
  - [AtomicRateLimiterTest](https://github.com/resilience4j/resilience4j/blob/master/resilience4j-ratelimiter/src/test/java/io/github/resilience4j/ratelimiter/internal/AtomicRateLimiterTest.java)
- Guava:
  - [RateLimiter](https://github.com/google/guava/blob/master/guava/src/com/google/common/util/concurrent/RateLimiter.java)
  - [RateLimiterTest](https://github.com/google/guava/blob/master/guava-tests/test/com/google/common/util/concurrent/RateLimiterTest.java)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2120496703

From egahlin at openjdk.org  Mon Jun  2 10:02:53 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 2 Jun 2025 10:02:53 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v2]
In-Reply-To: <uXeoMZ7n-Nb_hygLGtFpWwGR8W8ooZmHvVqBQmdzQWo=.22bb4db5-88f3-4b2a-a348-5162d84d0427@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <sdD_sCKqgIH47ozZr_JLBa38whUshwsAYpPhlb8YVbQ=.4dc670bc-2efd-4d73-a92b-982d40483d55@github.com>
 <uXeoMZ7n-Nb_hygLGtFpWwGR8W8ooZmHvVqBQmdzQWo=.22bb4db5-88f3-4b2a-a348-5162d84d0427@github.com>
Message-ID: <Vm8I6uPuFb9c9HvLs2k2AlmzzND58RLMNQSzaUJtIdY=.ed8d5612-b376-4ff3-9335-7286d5f1423c@github.com>

On Mon, 2 Jun 2025 08:59:57 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Some reviewer feedback
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/settings/Throttler.java line 30:
> 
>> 28: import java.util.concurrent.locks.ReentrantLock;
>> 29: import jdk.jfr.internal.PlatformEventType;
>> 30: public final class Throttler {
> 
> **Disclaimer:** I am a passer-by and I don't possess a deep JFR experience.
> 
> Throttling (aka. rate limiting) is a pretty much non-trivial functionality. Shall we
> 
> - Revamp the JavaDoc and document the used algorithm?
> - Have a dedicated test for `Throttler`? (I see that the newly added `TestThrottle` tests `@Throttle`, hence it also covers `Throttler`. Though there I could not see any verification based on the time[stamp] of events.)
> 
> ### References
> 
> - Resilience4j:
>   - [AtomicRateLimiter](https://github.com/resilience4j/resilience4j/blob/master/resilience4j-ratelimiter/src/main/java/io/github/resilience4j/ratelimiter/internal/AtomicRateLimiter.java)
>   - [AtomicRateLimiterTest](https://github.com/resilience4j/resilience4j/blob/master/resilience4j-ratelimiter/src/test/java/io/github/resilience4j/ratelimiter/internal/AtomicRateLimiterTest.java)
> - Guava:
>   - [RateLimiter](https://github.com/google/guava/blob/master/guava/src/com/google/common/util/concurrent/RateLimiter.java)
>   - [RateLimiterTest](https://github.com/google/guava/blob/master/guava-tests/test/com/google/common/util/concurrent/RateLimiterTest.java)

I don't think we want to write the algorithm in the specification. It would make it harder for us to make adjustments in the future. The contract is x events per time unit without details on how JFR adapts the sampling. The algorithm is the same one used by the jdk.ObjectAllocationSample event, which has been in use since JDK 16, but implemented in native code and with a gtest:
https://github.com/openjdk/jdk/blob/master/src/hotspot/share/jfr/support/jfrAdaptiveSampler.cpp
 
The code in the PR is a method per method port of that code. It's hard to write stable tests that include timestamps. We have tried that in the past for other settings/events, but it only resulted in false positives.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2120643350

From mgronlun at openjdk.org  Mon Jun  2 10:14:52 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 2 Jun 2025 10:14:52 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v2]
In-Reply-To: <KxlQQTym19WULE3miG6oD_hV6Zh4mSlw1zRHCswk0Eg=.82623696-1fac-4294-a187-07956c424814@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <Pb7W24qpASuvcdw8ElmNW-RubVkddYTqvzDQPGCvvrw=.6bec04d0-5dc0-493f-8ebd-d1595f3c4946@github.com>
 <KxlQQTym19WULE3miG6oD_hV6Zh4mSlw1zRHCswk0Eg=.82623696-1fac-4294-a187-07956c424814@github.com>
Message-ID: <nh7gTI3xUYTtMZigep1TusR2Pzu1QSdZ-zYjoMA00fs=.2ba97d70-8644-4975-8df0-96af982fc49c@github.com>

On Sun, 1 Jun 2025 13:07:50 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 256:
>> 
>>> 254:             // }
>>> 255:             getEventConfiguration(codeBuilder);
>>> 256:             codeBuilder.aload(0);
>> 
>> Can issue a dup() here if you want to avoid the second aload(0).
>
> I don't think it will work because the result of the first getField (startTime) will be on the stack, when we issue the next getField (duration).

No big deal, we can look into the details later.

>> src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 261:
>> 
>>> 259:             getfield(codeBuilder, eventClassDesc, ImplicitFields.FIELD_DURATION);
>>> 260:             Bytecode.invokevirtual(codeBuilder, TYPE_EVENT_CONFIGURATION, METHOD_THROTTLE);
>>> 261:             int result = codeBuilder.allocateLocal(TypeKind.LONG);
>> 
>> Do we really need to store the result in a local? Can't we just dup it on the expression stack and store it directly into the field after another aload, or dup? Perhaps dup twice to then issue the mask operation?
>
> We could do an aload(0) at the beginning, before getEventConfiguration(codeBuilder), to have "this" for putfield(duration) later, but then we would need to do a getfield(this.duration) to have it on the stack for the mask.
> 
> We can't do a dup() on duration because we need "this" on the stack to store it in this.duration. I thought using a local variable would be faster than accessing this.duration. It also reduces the chance of the value being changed by another thread.

No big deal, we can look into this later if the need arises.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2120675164
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2120676832

From michaelm at openjdk.org  Tue Jun  3 08:14:48 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 3 Jun 2025 08:14:48 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v19]
In-Reply-To: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
Message-ID: <vicgJ1AulH1JCrSUbP0nPu3FOPi1PLLKxJanl3FWjVM=.b0e75401-049c-45ee-855a-48d3f7678728@github.com>

> Hi,
> 
> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
> addresses from exception message strings, unless the enhanced mode for the specific category 
> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
> updated in 8207846.
> 
> This PR aims to increase the coverage of enhanced exception messages in the networking code.
> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
> (while preserving the existing behavior).
> 
> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
> a comma separated list of category names, which identify groups of exceptions where the exception
> message may be enhanced. Any category not listed is "restricted" which means that potentially
> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
> 
> The changes to the java.security conf file describe the exact changes in terms of the categories now
> supported and any changes in behavior.
> 
> Thanks,
> Michael

Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 39 commits:

 - Merge branch 'master' into 8348986-exceptions
 - doc update to java.security
 - removed jmod/Handler change
 - doc update to java.security
 - Fixed problem with j.n.HostPortRange
 - typo in suggestions and other issues
 - Merge branch 'master' into 8348986-exceptions
 - Apply suggestions from code review
   
   Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>
 - Additional callsites identified by Mark S.
 - Merge branch 'master' into 8348986-exceptions
 - ... and 29 more: https://git.openjdk.org/jdk/compare/dbf562c7...ab6387d8

-------------

Changes: https://git.openjdk.org/jdk/pull/23929/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=18
  Stats: 984 lines in 47 files changed: 709 ins; 101 del; 174 mod
  Patch: https://git.openjdk.org/jdk/pull/23929.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23929/head:pull/23929

PR: https://git.openjdk.org/jdk/pull/23929

From egahlin at openjdk.org  Tue Jun  3 12:50:49 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 3 Jun 2025 12:50:49 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v3]
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <DbxABSmBFyo8jlTL2jMdq-60DALxvrASNGrzVTzJRyQ=.a5452f1a-6144-452c-bec1-61e08f2548c0@github.com>

> Could I have review of an enhancement that adds rate-limited sampling to Java event, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:

  Fix adjust boundary

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25559/files
  - new: https://git.openjdk.org/jdk/pull/25559/files/d0097506..7fa2db19

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25559&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25559&range=01-02

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/25559.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25559/head:pull/25559

PR: https://git.openjdk.org/jdk/pull/25559

From mdonovan at openjdk.org  Tue Jun  3 13:11:31 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 3 Jun 2025 13:11:31 GMT
Subject: RFR: 8325766: Review seclibs tests for cert expiry [v5]
In-Reply-To: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com>
References: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com>
Message-ID: <hI_lj1mHbTu7TaGHfnnimE3MBTVbISe6wbyCx3fbyuQ=.fd5d771c-0e13-450b-a3ca-a79e2a21e088@github.com>

> This PR updates the CertificateBuilder with a new method that creates a new instance with common fields (subject name, public key, serial number, validity, and key uses) filled-in. One test, IPIdentities.java, is updated to show how the method can be used to create various certificates. I attached screenshots that compare the old hard-coded certificates (left) with the new generated certificates.
> 
> ![trusted-cert](https://github.com/user-attachments/assets/4bfaca10-74f3-4d24-9796-288358ae00e1)
> ![server-cert](https://github.com/user-attachments/assets/51ce8ed2-0784-44ab-96a1-9d0a2ea66aaa)
> ![client-cert](https://github.com/user-attachments/assets/5090a71e-ef7a-4303-ae1a-78f89878d1c0)

Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - fixed redundant setNotAfter() calls. One of them should have been setNotBefore
 - Merge branch 'master' into certbuilder
 - expanded wildcard imports
 - Merge branch 'master' into certbuilder
 - Merge branch 'master' into certbuilder
 - reversed order of DN strings when making certificates.
 - Merge branch 'master' into certbuilder
 - Merge branch 'master' into certbuilder
 - Merge branch 'master' into certbuilder
 - Merge branch 'master' into certbuilder
 - ... and 2 more: https://git.openjdk.org/jdk/compare/e490b4f0...2b5533aa

-------------

Changes: https://git.openjdk.org/jdk/pull/23700/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23700&range=04
  Stats: 784 lines in 3 files changed: 158 ins; 582 del; 44 mod
  Patch: https://git.openjdk.org/jdk/pull/23700.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23700/head:pull/23700

PR: https://git.openjdk.org/jdk/pull/23700

From mdonovan at openjdk.org  Tue Jun  3 13:18:01 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 3 Jun 2025 13:18:01 GMT
Subject: RFR: 8325766: Review seclibs tests for cert expiry [v4]
In-Reply-To: <5ZUVLPZoyfEyo4OcY_rdldmlcA3uLFN-Z09bYhoRNWs=.5abd252b-67dc-4b36-b6c4-2a7c842a7752@github.com>
References: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com>
 <gKN9ZEKWL18qr9QPDhtyitWoUPollUoVhvyUTSgCx3c=.eb059bd6-c1bb-4d5f-a3ff-9632011f6278@github.com>
 <5ZUVLPZoyfEyo4OcY_rdldmlcA3uLFN-Z09bYhoRNWs=.5abd252b-67dc-4b36-b6c4-2a7c842a7752@github.com>
Message-ID: <JA3afve_1nmCt4tvLBo_6sI4Ze15bCF34qzEAuE3z28=.08077ddc-0b7d-4013-b407-c9475335b1b4@github.com>

On Fri, 30 May 2025 19:28:27 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
>> 
>>  - expanded wildcard imports
>>  - Merge branch 'master' into certbuilder
>>  - Merge branch 'master' into certbuilder
>>  - reversed order of DN strings when making certificates.
>>  - Merge branch 'master' into certbuilder
>>  - Merge branch 'master' into certbuilder
>>  - Merge branch 'master' into certbuilder
>>  - Merge branch 'master' into certbuilder
>>  - changed boolean array initialization
>>  - 8325766: Review seclibs tests for cert expiry
>
> test/lib/jdk/test/lib/security/CertificateBuilder.java line 109:
> 
>> 107:      */
>> 108:     public static CertificateBuilder newCertificateBuilder(String subjectName,
>> 109:                            PublicKey publicKey, PublicKey caKey, KeyUsage... keyUsages)
> 
> My suggestion is to make this a regular constructor and have an additional method that sets the certificate lifetime as a `Duration` parameter, ex:
> 
> `new CertificateBuilder(subject, pubKey, caPubKey, keyUsage).withValidity(Duration.ofHours(1));`

I think the way it currently is follows the builder pattern better. All of the 'set' methods return `this` which means if I change this method to a constructor, I'd have to duplicate the "set" code from all those methods.

I like the idea of using `Duration` but the API for it doesn't really lend itself to this use case. When the certificate is finally created, we write `Date` objects to the DerOutputStream so I'd have to choose a start time and then calculate the end time based on the duration. It's not hard, but it doesn't seem worth it when the common use case of this class is to generate short-lived certificates for a test. The default one-hour validity will cover the vast majority of tests.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23700#discussion_r2123779281

From dfuchs at openjdk.org  Tue Jun  3 13:22:58 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 3 Jun 2025 13:22:58 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v19]
In-Reply-To: <vicgJ1AulH1JCrSUbP0nPu3FOPi1PLLKxJanl3FWjVM=.b0e75401-049c-45ee-855a-48d3f7678728@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <vicgJ1AulH1JCrSUbP0nPu3FOPi1PLLKxJanl3FWjVM=.b0e75401-049c-45ee-855a-48d3f7678728@github.com>
Message-ID: <Z9wuYyFiAHmGeI1K2E_tBDqs3kurtsXNmE327z_Io6Q=.248a8519-e3c3-436c-b597-b46195984eb2@github.com>

On Tue, 3 Jun 2025 08:14:48 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
>> addresses from exception message strings, unless the enhanced mode for the specific category 
>> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
>> updated in 8207846.
>> 
>> This PR aims to increase the coverage of enhanced exception messages in the networking code.
>> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
>> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
>> (while preserving the existing behavior).
>> 
>> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
>> a comma separated list of category names, which identify groups of exceptions where the exception
>> message may be enhanced. Any category not listed is "restricted" which means that potentially
>> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
>> 
>> The changes to the java.security conf file describe the exact changes in terms of the categories now
>> supported and any changes in behavior.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 39 commits:
> 
>  - Merge branch 'master' into 8348986-exceptions
>  - doc update to java.security
>  - removed jmod/Handler change
>  - doc update to java.security
>  - Fixed problem with j.n.HostPortRange
>  - typo in suggestions and other issues
>  - Merge branch 'master' into 8348986-exceptions
>  - Apply suggestions from code review
>    
>    Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>
>  - Additional callsites identified by Mark S.
>  - Merge branch 'master' into 8348986-exceptions
>  - ... and 29 more: https://git.openjdk.org/jdk/compare/dbf562c7...ab6387d8

Marked as reviewed by dfuchs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/23929#pullrequestreview-2892334027

From alanb at openjdk.org  Tue Jun  3 14:02:18 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 3 Jun 2025 14:02:18 GMT
Subject: RFR: 8358496: Concurrent reading from Socket with timeout executes
 sequentially
Message-ID: <r_VHFsOe5e0ruPkwhFE0dWSNohY3HBurIoMr2nwUjEc=.8da2e937-91f5-49e3-87b1-f1a282209f98@github.com>

If several threads attempt to read from a Socket's input stream at the same time then all but the winner will block trying to acquire the read lock.  This is okay for untimed-reads but surprising for timed-reads as the timeout is only effective after acquiring the lock. The SocketImpl is changed so that the timeout applies to the total time waiting to acquire and read.

A new test is added to the existing java/net/Socket/Timeouts test. It is migrated from TestNG to a JUnit test as a drive-by change - it's mostly mechanical and the changes kept as minimal as possible.

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/25614/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25614&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358496
  Stats: 173 lines in 2 files changed: 67 ins; 11 del; 95 mod
  Patch: https://git.openjdk.org/jdk/pull/25614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25614/head:pull/25614

PR: https://git.openjdk.org/jdk/pull/25614

From mgronlun at openjdk.org  Tue Jun  3 14:10:59 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 3 Jun 2025 14:10:59 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v3]
In-Reply-To: <DbxABSmBFyo8jlTL2jMdq-60DALxvrASNGrzVTzJRyQ=.a5452f1a-6144-452c-bec1-61e08f2548c0@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <DbxABSmBFyo8jlTL2jMdq-60DALxvrASNGrzVTzJRyQ=.a5452f1a-6144-452c-bec1-61e08f2548c0@github.com>
Message-ID: <8jbZNr-7dzvGRglSLxMcgr5WjmSrGRChJ8MQarUTkdo=.dc1c9dff-65da-4e75-a49c-9af112b26cc7@github.com>

On Tue, 3 Jun 2025 12:50:49 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
>> 
>> Testing: test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix adjust boundary

Great stuff.

We have now what amounts to a carbon-copy of the existing throttling implementation used in the JVM, mainly used by the jdk.ObjectAllocationSample event. (see hotspot/src/share/jfr/support/jfrAdaptiveSampler.cpp and hotspot/src/share/jfr/recorder/service/jfrEventThrottler.cpp).

Smart work to write the Java implementation as a method-to-method comparison, which made it easier to review.

Thanks
Markus

-------------

Marked as reviewed by mgronlun (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25559#pullrequestreview-2892579207

From michaelm at openjdk.org  Tue Jun  3 14:27:57 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 3 Jun 2025 14:27:57 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v20]
In-Reply-To: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
Message-ID: <hsUAHdr4P3y03WbiHc5STSivjrWY6Co24wF5Yx1v1PA=.03fc5d87-504d-4e55-92a8-e21d5bd49d2c@github.com>

> Hi,
> 
> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
> addresses from exception message strings, unless the enhanced mode for the specific category 
> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
> updated in 8207846.
> 
> This PR aims to increase the coverage of enhanced exception messages in the networking code.
> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
> (while preserving the existing behavior).
> 
> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
> a comma separated list of category names, which identify groups of exceptions where the exception
> message may be enhanced. Any category not listed is "restricted" which means that potentially
> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
> 
> The changes to the java.security conf file describe the exact changes in terms of the categories now
> supported and any changes in behavior.
> 
> Thanks,
> Michael

Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:

  uodate to JNDI

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/23929/files
  - new: https://git.openjdk.org/jdk/pull/23929/files/ab6387d8..1a6f5af2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23929&range=18-19

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/23929.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23929/head:pull/23929

PR: https://git.openjdk.org/jdk/pull/23929

From dfuchs at openjdk.org  Tue Jun  3 14:27:57 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 3 Jun 2025 14:27:57 GMT
Subject: RFR: 8348986: Improve coverage of enhanced exception messages
 [v20]
In-Reply-To: <hsUAHdr4P3y03WbiHc5STSivjrWY6Co24wF5Yx1v1PA=.03fc5d87-504d-4e55-92a8-e21d5bd49d2c@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
 <hsUAHdr4P3y03WbiHc5STSivjrWY6Co24wF5Yx1v1PA=.03fc5d87-504d-4e55-92a8-e21d5bd49d2c@github.com>
Message-ID: <ipCTRLZJFZ552tbf9IHpkAhXwOtPdgOXDPmliSJieUc=.f0ed0520-c99d-4d6f-ad46-03891f10ca76@github.com>

On Tue, 3 Jun 2025 14:23:54 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi,
>> 
>> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
>> addresses from exception message strings, unless the enhanced mode for the specific category 
>> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
>> updated in 8207846.
>> 
>> This PR aims to increase the coverage of enhanced exception messages in the networking code.
>> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
>> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
>> (while preserving the existing behavior).
>> 
>> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
>> a comma separated list of category names, which identify groups of exceptions where the exception
>> message may be enhanced. Any category not listed is "restricted" which means that potentially
>> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
>> 
>> The changes to the java.security conf file describe the exact changes in terms of the categories now
>> supported and any changes in behavior.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   uodate to JNDI

Thanks for the last updates Michael. I believe we're good now!

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23929#pullrequestreview-2892676320

From dfuchs at openjdk.org  Tue Jun  3 15:26:53 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 3 Jun 2025 15:26:53 GMT
Subject: RFR: 8358496: Concurrent reading from Socket with timeout executes
 sequentially
In-Reply-To: <r_VHFsOe5e0ruPkwhFE0dWSNohY3HBurIoMr2nwUjEc=.8da2e937-91f5-49e3-87b1-f1a282209f98@github.com>
References: <r_VHFsOe5e0ruPkwhFE0dWSNohY3HBurIoMr2nwUjEc=.8da2e937-91f5-49e3-87b1-f1a282209f98@github.com>
Message-ID: <oOVwHGW_Gfwf1WZkttZYuZnzN-rHfnSFexA0vqZtSx0=.75a004cb-5ea1-474c-9707-041fd06a1ac7@github.com>

On Tue, 3 Jun 2025 12:56:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> If several threads attempt to read from a Socket's input stream at the same time then all but the winner will block trying to acquire the read lock.  This is okay for untimed-reads but surprising for timed-reads as the timeout is only effective after acquiring the lock. The SocketImpl is changed so that the timeout applies to the total time waiting to acquire and read.
> 
> A new test is added to the existing java/net/Socket/Timeouts test. It is migrated from TestNG to a JUnit test as a drive-by change - it's mostly mechanical and the changes kept as minimal as possible.

Changes LGTM. Minor comment on the test.

test/jdk/java/net/Socket/Timeouts.java line 80:

> 78:         try (Socket s = new Socket()) {
> 79:             SocketAddress remote = Utils.refusingEndpoint();
> 80:             assertThrows(ConnectException.class,  () -> s.connect(remote, 10000));

Ah! Good - you're even fixing a bug here.

test/jdk/java/net/Socket/Timeouts.java line 249:

> 247:                         () -> s.getInputStream().read());
> 248:                 int timeout = s.getSoTimeout();
> 249:                 checkDuration(startMillis, timeout-100, timeout+20_000);

Maybe it would be worth noting here that if the bug isn't fixed, the last thread to call read() would have to wait for 200 seconds, which largely exceeds 22s?

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25614#pullrequestreview-2893023129
PR Review Comment: https://git.openjdk.org/jdk/pull/25614#discussion_r2124221517
PR Review Comment: https://git.openjdk.org/jdk/pull/25614#discussion_r2124218812

From mullan at openjdk.org  Tue Jun  3 15:33:56 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 3 Jun 2025 15:33:56 GMT
Subject: RFR: 8325766: Review seclibs tests for cert expiry [v4]
In-Reply-To: <JA3afve_1nmCt4tvLBo_6sI4Ze15bCF34qzEAuE3z28=.08077ddc-0b7d-4013-b407-c9475335b1b4@github.com>
References: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com>
 <gKN9ZEKWL18qr9QPDhtyitWoUPollUoVhvyUTSgCx3c=.eb059bd6-c1bb-4d5f-a3ff-9632011f6278@github.com>
 <5ZUVLPZoyfEyo4OcY_rdldmlcA3uLFN-Z09bYhoRNWs=.5abd252b-67dc-4b36-b6c4-2a7c842a7752@github.com>
 <JA3afve_1nmCt4tvLBo_6sI4Ze15bCF34qzEAuE3z28=.08077ddc-0b7d-4013-b407-c9475335b1b4@github.com>
Message-ID: <Zgvh4-Dv0d227pBcvwQJWpslMAYKsFcXgFNLl_fUKkg=.096b15a3-fdb5-40a0-a336-f0638c5abbc0@github.com>

On Tue, 3 Jun 2025 13:15:33 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> I think the way it currently is follows the builder pattern better. All of the 'set' methods return `this` which means if I change this method to a constructor, I'd have to duplicate the "set" code from all those methods.

I'm not sure what you mean - can you give an example? I don't see any advantages of using a static method here, but I agree it works either way.

> I like the idea of using `Duration` but the API for it doesn't really lend itself to this use case. When the certificate is finally created, we write `Date` objects to the DerOutputStream so I'd have to choose a start time and then calculate the end time based on the duration. It's not hard, but it doesn't seem worth it when the common use case of this class is to generate short-lived certificates for a test. The default one-hour validity will cover the vast majority of tests.

I view this test utility class as being flexible enough for different cases. This is a useful method in that the other parameters are common fields that all certs usually have but it also means I can't use this method to to create a certificate with a longer, or shorter validity period. Alternatively, how about adding another method that hard-codes it as one hour:

`CertificateBuilder oneHourValidity()`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23700#discussion_r2124254602

From michaelm at openjdk.org  Tue Jun  3 15:39:06 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 3 Jun 2025 15:39:06 GMT
Subject: Integrated: 8348986: Improve coverage of enhanced exception messages
In-Reply-To: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
References: <FTLKwerWMHpHiWyFhzNgAkOyr1awsvVqUoX6UiQ1tno=.8919eec1-d2d3-4586-a8e9-2106f677c94e@github.com>
Message-ID: <ANCJMV9FtfHoAU_5eMxPFITXqxhqUwFM7UMQW1kicBQ=.57bfe450-373c-45b6-94a8-4a8b33c873f4@github.com>

On Thu, 6 Mar 2025 10:24:13 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Hi,
> 
> Enhanced exception messages are designed to hide sensitive information such as hostnames, IP 
> addresses from exception message strings, unless the enhanced mode for the specific category 
> has been explicitly enabled. Enhanced exceptions were first introduced in 8204233 in JDK 11 and 
> updated in 8207846.
> 
> This PR aims to increase the coverage of enhanced exception messages in the networking code.
> A limited number of exceptions are already hidden (restricted) by default. The new categories and 
> exceptions in this PR will be restricted on an opt-in basis, ie. the default mode will be enhanced
> (while preserving the existing behavior).
> 
> The mechanism is controlled by the security/system property "jdk.includeInExceptions" which takes as value
> a comma separated list of category names, which identify groups of exceptions where the exception
> message may be enhanced. Any category not listed is "restricted" which means that potentially
> sensitive information (such as hostnames, IP addresses, user identities) are excluded from the message text.
> 
> The changes to the java.security conf file describe the exact changes in terms of the categories now
> supported and any changes in behavior.
> 
> Thanks,
> Michael

This pull request has now been integrated.

Changeset: b6f827ef
Author:    Michael McMahon <michaelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b6f827ef054959662190e21ce63fc3d3c45b92f3
Stats:     984 lines in 47 files changed: 709 ins; 101 del; 174 mod

8348986: Improve coverage of enhanced exception messages

Reviewed-by: dfuchs

-------------

PR: https://git.openjdk.org/jdk/pull/23929

From mdonovan at openjdk.org  Tue Jun  3 16:05:55 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 3 Jun 2025 16:05:55 GMT
Subject: RFR: 8325766: Review seclibs tests for cert expiry [v4]
In-Reply-To: <Zgvh4-Dv0d227pBcvwQJWpslMAYKsFcXgFNLl_fUKkg=.096b15a3-fdb5-40a0-a336-f0638c5abbc0@github.com>
References: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com>
 <gKN9ZEKWL18qr9QPDhtyitWoUPollUoVhvyUTSgCx3c=.eb059bd6-c1bb-4d5f-a3ff-9632011f6278@github.com>
 <5ZUVLPZoyfEyo4OcY_rdldmlcA3uLFN-Z09bYhoRNWs=.5abd252b-67dc-4b36-b6c4-2a7c842a7752@github.com>
 <JA3afve_1nmCt4tvLBo_6sI4Ze15bCF34qzEAuE3z28=.08077ddc-0b7d-4013-b407-c9475335b1b4@github.com>
 <Zgvh4-Dv0d227pBcvwQJWpslMAYKsFcXgFNLl_fUKkg=.096b15a3-fdb5-40a0-a336-f0638c5abbc0@github.com>
Message-ID: <3Vzkj4wL99IHs48Ys_zXUzRCiOEm5jjh5Oilop5dSDM=.d945fcf2-3f0b-4e34-8673-96928dc47952@github.com>

On Tue, 3 Jun 2025 15:31:37 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> I think the way it currently is follows the builder pattern better. All of the 'set' methods return `this` which means if I change this method to a constructor, I'd have to duplicate the "set" code from all those methods.
>> 
>> I like the idea of using `Duration` but the API for it doesn't really lend itself to this use case. When the certificate is finally created, we write `Date` objects to the DerOutputStream so I'd have to choose a start time and then calculate the end time based on the duration. It's not hard, but it doesn't seem worth it when the common use case of this class is to generate short-lived certificates for a test. The default one-hour validity will cover the vast majority of tests.
>
>> I think the way it currently is follows the builder pattern better. All of the 'set' methods return `this` which means if I change this method to a constructor, I'd have to duplicate the "set" code from all those methods.
> 
> I'm not sure what you mean - can you give an example? I don't see any advantages of using a static method here, but I agree it works either way.
> 
>> I like the idea of using `Duration` but the API for it doesn't really lend itself to this use case. When the certificate is finally created, we write `Date` objects to the DerOutputStream so I'd have to choose a start time and then calculate the end time based on the duration. It's not hard, but it doesn't seem worth it when the common use case of this class is to generate short-lived certificates for a test. The default one-hour validity will cover the vast majority of tests.
> 
> I view this test utility class as being flexible enough for different cases. This is a useful method in that the other parameters are common fields that all certs usually have but it also means I can't use this method to to create a certificate with a longer, or shorter validity period. Alternatively, how about adding another method that hard-codes it as one hour:
> 
> `CertificateBuilder oneHourValidity()`

As a constructor, the code would look like this


public CertificateBuilder(String subjectName,
                              PublicKey publicKey, PublicKey caKey, KeyUsage... keyUsages)
            throws CertificateException, IOException {
        factory = CertificateFactory.getInstance("X.509");
        SecureRandom random = new SecureRandom();

        boolean [] keyUsage = new boolean[KeyUsage.values().length];
        for (KeyUsage ku : keyUsages) {
            keyUsage[ku.ordinal()] = true;
        }

        this.subjectName = new X500Principal(subjectName);
        this.publicKey = Objects.requireNonNull(publicKey, "Caught null public key");
        notBefore = (Date)Date.from(Instant.now().minus(1, ChronoUnit.HOURS));
        notAfter = Date.from(Instant.now().plus(1, ChronoUnit.HOURS));
        serialNumber = BigInteger.valueOf(random.nextLong(1000000)+1);
        byte[] keyIdBytes = new KeyIdentifier(publicKey).getIdentifier();
        Extension e = new SubjectKeyIdentifierExtension(keyIdBytes);
        extensions.put(e.getId(), e);

        KeyIdentifier kid = new KeyIdentifier(caKey);
        e = new AuthorityKeyIdentifierExtension(kid, null, null);
        extensions.put(e.getId(), e);

        if (keyUsages.length != 0) {
            e = new KeyUsageExtension(keyUsage);
            extensions.put(e.getId(), e);
        }
    }



>   it also means I can't use this method to to create a certificate with a longer, or shorter validity period

There are methods to set the not-before and not-after fields. Any field set in this static method can be changed:

`
newCertificateBuilder(...).notAfter(Date.from(Instant.now().plus(10, TimeUnit.YEARS)));
`

I don't like using `Date` here and would be happy to overload it to take `Instant` as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23700#discussion_r2124330323

From alanb at openjdk.org  Tue Jun  3 16:10:38 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 3 Jun 2025 16:10:38 GMT
Subject: RFR: 8358496: Concurrent reading from Socket with timeout executes
 sequentially [v2]
In-Reply-To: <r_VHFsOe5e0ruPkwhFE0dWSNohY3HBurIoMr2nwUjEc=.8da2e937-91f5-49e3-87b1-f1a282209f98@github.com>
References: <r_VHFsOe5e0ruPkwhFE0dWSNohY3HBurIoMr2nwUjEc=.8da2e937-91f5-49e3-87b1-f1a282209f98@github.com>
Message-ID: <O5nTjJzL7tQyn4q_cfv1yTpGbfgIjUg1k9d1RkO0Qfs=.ec618e60-6d7c-4570-9ee8-1ffda5912f01@github.com>

> If several threads attempt to read from a Socket's input stream at the same time then all but the winner will block trying to acquire the read lock.  This is okay for untimed-reads but surprising for timed-reads as the timeout is only effective after acquiring the lock. The SocketImpl is changed so that the timeout applies to the total time waiting to acquire and read.
> 
> A new test is added to the existing java/net/Socket/Timeouts test. It is migrated from TestNG to a JUnit test as a drive-by change - it's mostly mechanical and the changes kept as minimal as possible.

Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:

  Make test comment cleaner

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25614/files
  - new: https://git.openjdk.org/jdk/pull/25614/files/80fe13b1..3dc870ed

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25614&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25614&range=00-01

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25614/head:pull/25614

PR: https://git.openjdk.org/jdk/pull/25614

From alanb at openjdk.org  Tue Jun  3 16:10:38 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 3 Jun 2025 16:10:38 GMT
Subject: RFR: 8358496: Concurrent reading from Socket with timeout executes
 sequentially [v2]
In-Reply-To: <oOVwHGW_Gfwf1WZkttZYuZnzN-rHfnSFexA0vqZtSx0=.75a004cb-5ea1-474c-9707-041fd06a1ac7@github.com>
References: <r_VHFsOe5e0ruPkwhFE0dWSNohY3HBurIoMr2nwUjEc=.8da2e937-91f5-49e3-87b1-f1a282209f98@github.com>
 <oOVwHGW_Gfwf1WZkttZYuZnzN-rHfnSFexA0vqZtSx0=.75a004cb-5ea1-474c-9707-041fd06a1ac7@github.com>
Message-ID: <YdG_G79PYHPkos945VgqkiENqelgzIymYdmV8Oj6EIA=.da1bcdef-630f-4bbe-aceb-8f9ca7a90235@github.com>

On Tue, 3 Jun 2025 15:20:48 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make test comment cleaner
>
> test/jdk/java/net/Socket/Timeouts.java line 249:
> 
>> 247:                         () -> s.getInputStream().read());
>> 248:                 int timeout = s.getSoTimeout();
>> 249:                 checkDuration(startMillis, timeout-100, timeout+20_000);
> 
> Maybe it would be worth noting here that if the bug isn't fixed, the last thread to call read() would have to wait for 200 seconds, which largely exceeds 22s?

Okay, I can make the test method description a bit clearer on this point.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25614#discussion_r2124337179

From dfuchs at openjdk.org  Tue Jun  3 16:24:56 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 3 Jun 2025 16:24:56 GMT
Subject: RFR: 8358496: Concurrent reading from Socket with timeout executes
 sequentially [v2]
In-Reply-To: <O5nTjJzL7tQyn4q_cfv1yTpGbfgIjUg1k9d1RkO0Qfs=.ec618e60-6d7c-4570-9ee8-1ffda5912f01@github.com>
References: <r_VHFsOe5e0ruPkwhFE0dWSNohY3HBurIoMr2nwUjEc=.8da2e937-91f5-49e3-87b1-f1a282209f98@github.com>
 <O5nTjJzL7tQyn4q_cfv1yTpGbfgIjUg1k9d1RkO0Qfs=.ec618e60-6d7c-4570-9ee8-1ffda5912f01@github.com>
Message-ID: <M0LpoQIix4h2-UdKGpKlzto-oTJlt_yVYqXuJ50QPng=.43294b15-4393-4e8e-8cbb-a9d3847ef88d@github.com>

On Tue, 3 Jun 2025 16:10:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> If several threads attempt to read from a Socket's input stream at the same time then all but the winner will block trying to acquire the read lock.  This is okay for untimed-reads but surprising for timed-reads as the timeout is only effective after acquiring the lock. The SocketImpl is changed so that the timeout applies to the total time waiting to acquire and read.
>> 
>> A new test is added to the existing java/net/Socket/Timeouts test. It is migrated from TestNG to a JUnit test as a drive-by change - it's mostly mechanical and the changes kept as minimal as possible.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make test comment cleaner

Marked as reviewed by dfuchs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25614#pullrequestreview-2893258189

From mullan at openjdk.org  Tue Jun  3 17:37:07 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 3 Jun 2025 17:37:07 GMT
Subject: RFR: 8325766: Review seclibs tests for cert expiry [v4]
In-Reply-To: <3Vzkj4wL99IHs48Ys_zXUzRCiOEm5jjh5Oilop5dSDM=.d945fcf2-3f0b-4e34-8673-96928dc47952@github.com>
References: <4HflFT8pQ4MtxxF0QmyeIzPV8u3rBMdCGJaPx8UN5Dc=.20f68ae8-349a-4c1e-ba38-c27b3b1bbfee@github.com>
 <gKN9ZEKWL18qr9QPDhtyitWoUPollUoVhvyUTSgCx3c=.eb059bd6-c1bb-4d5f-a3ff-9632011f6278@github.com>
 <5ZUVLPZoyfEyo4OcY_rdldmlcA3uLFN-Z09bYhoRNWs=.5abd252b-67dc-4b36-b6c4-2a7c842a7752@github.com>
 <JA3afve_1nmCt4tvLBo_6sI4Ze15bCF34qzEAuE3z28=.08077ddc-0b7d-4013-b407-c9475335b1b4@github.com>
 <Zgvh4-Dv0d227pBcvwQJWpslMAYKsFcXgFNLl_fUKkg=.096b15a3-fdb5-40a0-a336-f0638c5abbc0@github.com>
 <3Vzkj4wL99IHs48Ys_zXUzRCiOEm5jjh5Oilop5dSDM=.d945fcf2-3f0b-4e34-8673-96928dc47952@github.com>
Message-ID: <xEMRItOXiz4QiIfzOGi5uyciDwMlL_RXN-mqbMWK7D0=.22861fb0-6375-43cc-be8f-04e42d03de5c@github.com>

On Tue, 3 Jun 2025 16:03:09 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> As a constructor, the code would look like this

<snip>

Ah, I see. Well technically you could call the set methods from the ctor but you would get `this-escape` compiler warnings, which you probably want to avoid.

> > it also means I can't use this method to to create a certificate with a longer, or shorter validity period
> 
> There are methods to set the not-before and not-after fields. Any field set in this static method can be changed:
> 
> `newCertificateBuilder(...).notAfter(Date.from(Instant.now().plus(10, TimeUnit.YEARS)));`
> 
> I don't like using `Date` here and would be happy to overload it to take `Instant` as well.

Yes, but I don't think the static method which is generically named `newCertificateBuilder` should be hard-coding a one hour validity period, that detail should be either in a different method (my preference) or this method should be named more clearly like `oneHourCertificateBuilder`. I realize this is just a test method, but this is a nicely designed API that has been very useful so I would prefer if we keep the flexibility.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23700#discussion_r2124489674

From alanb at openjdk.org  Wed Jun  4 09:55:20 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 4 Jun 2025 09:55:20 GMT
Subject: Integrated: 8358496: Concurrent reading from Socket with timeout
 executes sequentially
In-Reply-To: <r_VHFsOe5e0ruPkwhFE0dWSNohY3HBurIoMr2nwUjEc=.8da2e937-91f5-49e3-87b1-f1a282209f98@github.com>
References: <r_VHFsOe5e0ruPkwhFE0dWSNohY3HBurIoMr2nwUjEc=.8da2e937-91f5-49e3-87b1-f1a282209f98@github.com>
Message-ID: <LGLho4LhsxCtg1IMn5zM3Cd9SAadVqAe379f5yresjk=.00fa5169-fca7-4f6d-8c6a-93b2e76a7d04@github.com>

On Tue, 3 Jun 2025 12:56:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> If several threads attempt to read from a Socket's input stream at the same time then all but the winner will block trying to acquire the read lock.  This is okay for untimed-reads but surprising for timed-reads as the timeout is only effective after acquiring the lock. The SocketImpl is changed so that the timeout applies to the total time waiting to acquire and read.
> 
> A new test is added to the existing java/net/Socket/Timeouts test. It is migrated from TestNG to a JUnit test as a drive-by change - it's mostly mechanical and the changes kept as minimal as possible.

This pull request has now been integrated.

Changeset: 7838321b
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7838321b74276e45b92c54904ea31ef70ed9e33f
Stats:     174 lines in 2 files changed: 68 ins; 11 del; 95 mod

8358496: Concurrent reading from Socket with timeout executes sequentially

Reviewed-by: dfuchs

-------------

PR: https://git.openjdk.org/jdk/pull/25614

From egahlin at openjdk.org  Wed Jun  4 11:34:24 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 4 Jun 2025 11:34:24 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v3]
In-Reply-To: <DbxABSmBFyo8jlTL2jMdq-60DALxvrASNGrzVTzJRyQ=.a5452f1a-6144-452c-bec1-61e08f2548c0@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <DbxABSmBFyo8jlTL2jMdq-60DALxvrASNGrzVTzJRyQ=.a5452f1a-6144-452c-bec1-61e08f2548c0@github.com>
Message-ID: <bLfJIXOSXfrN-_id6hgutPMxJyeDvfya-o5X8x5AsEc=.8582bbda-fb3e-4d18-992c-c9699b8f68f3@github.com>

On Tue, 3 Jun 2025 12:50:49 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
>> 
>> Testing: test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix adjust boundary

@AlanBateman Do you have time for a review?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25559#issuecomment-2939669198

From alanb at openjdk.org  Wed Jun  4 12:10:20 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 4 Jun 2025 12:10:20 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v3]
In-Reply-To: <bLfJIXOSXfrN-_id6hgutPMxJyeDvfya-o5X8x5AsEc=.8582bbda-fb3e-4d18-992c-c9699b8f68f3@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <DbxABSmBFyo8jlTL2jMdq-60DALxvrASNGrzVTzJRyQ=.a5452f1a-6144-452c-bec1-61e08f2548c0@github.com>
 <bLfJIXOSXfrN-_id6hgutPMxJyeDvfya-o5X8x5AsEc=.8582bbda-fb3e-4d18-992c-c9699b8f68f3@github.com>
Message-ID: <us23R2nkGfg4Fisd7aTuf2-qDgnmaTn7sbqe0wuvphc=.ee7dcfdb-ae16-4f97-bae6-0328079a09ed@github.com>

On Wed, 4 Jun 2025 11:31:21 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> @AlanBateman Do you have time for a review?

Yes, looking at the changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25559#issuecomment-2939787559

From duke at openjdk.org  Wed Jun  4 13:16:11 2025
From: duke at openjdk.org (p-nima)
Date: Wed, 4 Jun 2025 13:16:11 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit of 3
 retries
Message-ID: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>

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.

-------------

Commit messages:
 - add comment to indicate system default value
 - apply review feedback
 - fix for the http client default retry limit

Changes: https://git.openjdk.org/jdk/pull/25490/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25490&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340182
  Stats: 118 lines in 2 files changed: 116 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/25490.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25490/head:pull/25490

PR: https://git.openjdk.org/jdk/pull/25490

From vyazici at openjdk.org  Wed Jun  4 13:16:17 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 4 Jun 2025 13:16:17 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit
 of 3 retries
In-Reply-To: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
Message-ID: <4-0FPfF_TcDB7t9yJLz94MM7cPc77dtrMI9-p03O5pc=.45d4d22c-232c-473e-9b15-9d9392c48cfa@github.com>

On Wed, 28 May 2025 11:26:17 GMT, p-nima <duke at openjdk.org> 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.

Changes requested by vyazici (Author).

@p-nima, thanks for quickly addressing the review feedback. I've dropped some further remarks.

test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 34:

> 32:  * @build jdk.httpclient.test.lib.http2.Http2TestServer
> 33:  * @run junit HttpClientRetryLimitTest
> 34:  * @run junit/othervm -Djdk.httpclient.auth.retrylimit=1 HttpClientRetryLimitTest

@dfuch, shall we test against zero and negative values too? (Both are accepted by `AuthenticationFilter` as valid.)

test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 49:

> 47: import static jdk.test.lib.Asserts.assertEquals;
> 48: 
> 49: public class HttpClientRetryLimitTest implements HttpServerAdapters {

*Nit:* [JUnit recommends the following](https://junit.org/junit5/docs/snapshot/user-guide/#writing-tests-classes-and-methods)
> It is generally recommended to omit the public modifier for test classes, test methods, and lifecycle methods unless there is a technical reason for doing so ...

test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 52:

> 50: 
> 51:     private static final int DEFAULT_RETRY_LIMIT = 3;
> 52:     private final int retryLimit = Integer.getInteger("jdk.httpclient.auth.retrylimit", DEFAULT_RETRY_LIMIT);

This can be `static` too.

test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 53:

> 51:     private static final int DEFAULT_RETRY_LIMIT = 3;
> 52:     private final int retryLimit = Integer.getInteger("jdk.httpclient.auth.retrylimit", DEFAULT_RETRY_LIMIT);
> 53:     private int countRetries;

This should better be converted to a local variable.

test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 57:

> 55: 
> 56: 
> 57: class HttpClientRetryLimitTest implements HttpServerAdapters {

Shall we rename this to `HttpClientAuthRetryLimit`, since [there are several other retry limits](https://docs.oracle.com/en/java/javase/23/docs/api/java.net.http/module-summary.html#jdk.httpclient.auth.retrylimit)?

test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 58:

> 56:     public void testDefaultSystemProperty() throws Exception {
> 57: 
> 58:         try (HttpTestServer httpTestServer = HttpTestServer.create(HttpClient.Version.HTTP_1_1)) {

Don't we need to verify the behavior for HTTP/2 too? If so, can we use a `@ParameterizedTest` instead and receive the protocol version? (There are several examples you can get inspired from; `HttpResponseConnectionLabelTest`, `EmptyAuthenticate`, etc.)

test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 64:

> 62:             "jdk.httpclient.auth.retrylimit", DEFAULT_RETRY_LIMIT);
> 63: 
> 64:     static Stream<HttpClient.Version> args() {

I think we should also test against with SSL and without SSL cases. See `HttpResponseLimitingTest.ServerClientPair` for inspiration.

test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 66:

> 64:             };
> 65: 
> 66:             httpTestServer.addHandler(httpTestHandler, "/");

In the past, there has been occasions in CI where a test server received connections from a totally unrelated test running in parallel on the same host. To avoid such mishaps, we better salt the path a bit by, say, appending the class' simple name?

test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 69:

> 67:             httpTestServer.start();
> 68: 
> 69:             countRetries = 0;

IMHO, this should be an `Atomic{Integer,Long}` due to the possibility of concurrent updates.

test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 73:

> 71:     @ParameterizedTest
> 72:     @MethodSource("args")
> 73:     public void testDefaultSystemProperty(HttpClient.Version version) throws Exception {

I see you made the class package-private in 18bac9f. You could have additionally made the method package-private too.

test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 87:

> 85:                         .build();
> 86: 
> 87:                 client.send(request, HttpResponse.BodyHandlers.ofString());

Since we're not interested in the response, `BodyHandlers.discarding()` might be a better fit here.

test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 88:

> 86:             try (
> 87:                 HttpClient client = HttpClient.newBuilder()
> 88:                         .authenticator(new Authenticator() {

To ensure the client will fire the request using the protocol version of our preference, could you also pass `version` to the client builder too, please?

test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 92:

> 90:                         "Expected number of retries was " + retryLimit + " but actual was "+countRetries);
> 91:                 e.printStackTrace();
> 92:             }

AFAIU, you should

1. Wrap `client::send` with `assertThrows`
2. Verify the returned exception
1. Then `assertEquals` the retry count

Otherwise, if `client::send` _unexpectedly_ doesn't throw anything, your test will incorrectly succeed.

test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 99:

> 97:                 HttpRequest request = HttpRequest.newBuilder()
> 98:                         .GET()
> 99:                         .uri(new URI("http://" + httpTestServer.serverAuthority() + "/" + this.getClass().getSimpleName() + "/"))

To ensure the client will fire the request using the protocol version of our preference, could you also pass `version` to the request builder too, please?

test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 113:

> 111:                 }
> 112:                 e.printStackTrace();
> 113:             }

AFAICT, you should be using `assertThrows` as follows:


IOException exception = assertThrows(...);
assertEquals(exception.message(), "too many authentication attempts. Limit: " + RETRY_LIMIT);
assertEquals(requestCount.get(), RETRY_LIMIT > 0 ? RETRY_LIMIT : 1);

-------------

PR Review: https://git.openjdk.org/jdk/pull/25490#pullrequestreview-2874776142
Changes requested by vyazici (Author).

PR Review: https://git.openjdk.org/jdk/pull/25490#pullrequestreview-2880603038
PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2111767554
PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2111701285
PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2111701781
PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2111702335
PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2116087627
PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2111743245
PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2116060516
PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2111722490
PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2111704822
PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2115470192
PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2111730359
PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2115451397
PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2111760843
PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2115449940
PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2115466187

From myankelevich at openjdk.org  Wed Jun  4 13:16:17 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Wed, 4 Jun 2025 13:16:17 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit
 of 3 retries
In-Reply-To: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
Message-ID: <Wyr03oYZrq3z6b6tb1Wv_YEPHkyXAK3qB3iamhnFNz8=.9a02744a-1373-4834-b488-d201e9fff501@github.com>

On Wed, 28 May 2025 11:26:17 GMT, p-nima <duke at openjdk.org> 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.

test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 34:

> 32:  * @build jdk.httpclient.test.lib.http2.Http2TestServer
> 33:  * @run junit HttpClientRetryLimitTest
> 34:  * @run junit/othervm -Djdk.httpclient.auth.retrylimit=1 HttpClientRetryLimitTest

Do you think adding a retrylimit=0 would be beneficial too? This way every scenario would be covered

test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 47:

> 45: import java.net.http.HttpResponse;
> 46: 
> 47: import static jdk.test.lib.Asserts.assertEquals;

minor: Did you mean `import static org.junit.jupiter.api.Assertions.assertEquals;` here, as you're using junit?

test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 52:

> 50: 
> 51:     private static final int DEFAULT_RETRY_LIMIT = 3;
> 52:     private final int retryLimit = Integer.getInteger("jdk.httpclient.auth.retrylimit", DEFAULT_RETRY_LIMIT);

Nit: This feels a bit confusing to me when reading it the first time, why not have a retry limit of 1 or 0 as a default and then specify if you want more retries in `@test`?
I think it might be a bit easier to read, but if you want to keep it, it's fine with me.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2111682350
PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2111670821
PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2111681002

From dfuchs at openjdk.org  Wed Jun  4 13:16:18 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 4 Jun 2025 13:16:18 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit
 of 3 retries
In-Reply-To: <4-0FPfF_TcDB7t9yJLz94MM7cPc77dtrMI9-p03O5pc=.45d4d22c-232c-473e-9b15-9d9392c48cfa@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
 <4-0FPfF_TcDB7t9yJLz94MM7cPc77dtrMI9-p03O5pc=.45d4d22c-232c-473e-9b15-9d9392c48cfa@github.com>
Message-ID: <Ne6MShrbDfh8xQbze1nkiz12CS8bu2iUJ2Q81K7xxgo=.5ff9f88b-7e1d-435e-bbb8-a19761b06421@github.com>

On Wed, 28 May 2025 12:46:25 GMT, Volkan Yazici <vyazici at openjdk.org> 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.
>
> test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 34:
> 
>> 32:  * @build jdk.httpclient.test.lib.http2.Http2TestServer
>> 33:  * @run junit HttpClientRetryLimitTest
>> 34:  * @run junit/othervm -Djdk.httpclient.auth.retrylimit=1 HttpClientRetryLimitTest
> 
> @dfuch, shall we test against zero and negative values too? (Both are accepted by `AuthenticationFilter` as valid.)

We could. We could also throw in garbage to see what happens.

> test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 57:
> 
>> 55: 
>> 56: 
>> 57: class HttpClientRetryLimitTest implements HttpServerAdapters {
> 
> Shall we rename this to `HttpClientAuthRetryLimit`, since [there are several other retry limits](https://docs.oracle.com/en/java/javase/23/docs/api/java.net.http/module-summary.html#jdk.httpclient.auth.retrylimit)?

Sounds reasonable to rename - and fix the `@summary` in the jtreg headers too

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2111954811
PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2116093435

From duke at openjdk.org  Wed Jun  4 13:16:18 2025
From: duke at openjdk.org (p-nima)
Date: Wed, 4 Jun 2025 13:16:18 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit
 of 3 retries
In-Reply-To: <Wyr03oYZrq3z6b6tb1Wv_YEPHkyXAK3qB3iamhnFNz8=.9a02744a-1373-4834-b488-d201e9fff501@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
 <Wyr03oYZrq3z6b6tb1Wv_YEPHkyXAK3qB3iamhnFNz8=.9a02744a-1373-4834-b488-d201e9fff501@github.com>
Message-ID: <MKkfHg-OsQHJ6cwoY-5Tt1Y3gSf9EiRqL6ldmUpiSFE=.4d3f89cd-d0a3-428c-81bb-a1eb675505f5@github.com>

On Wed, 28 May 2025 12:05:20 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> 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.
>
> test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 34:
> 
>> 32:  * @build jdk.httpclient.test.lib.http2.Http2TestServer
>> 33:  * @run junit HttpClientRetryLimitTest
>> 34:  * @run junit/othervm -Djdk.httpclient.auth.retrylimit=1 HttpClientRetryLimitTest
> 
> Do you think adding a retrylimit=0 would be beneficial too? This way every scenario would be covered

Added additional test case scenarios in 18bac9fa64f81110c2894f5f141e88ec5dc20b03

> test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 47:
> 
>> 45: import java.net.http.HttpResponse;
>> 46: 
>> 47: import static jdk.test.lib.Asserts.assertEquals;
> 
> minor: Did you mean `import static org.junit.jupiter.api.Assertions.assertEquals;` here, as you're using junit?

Thank you for your review. The changes have been made in 18bac9fa64f81110c2894f5f141e88ec5dc20b03

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2114264448
PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2114259866

From duke at openjdk.org  Wed Jun  4 13:16:18 2025
From: duke at openjdk.org (p-nima)
Date: Wed, 4 Jun 2025 13:16:18 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit
 of 3 retries
In-Reply-To: <Ne6MShrbDfh8xQbze1nkiz12CS8bu2iUJ2Q81K7xxgo=.5ff9f88b-7e1d-435e-bbb8-a19761b06421@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
 <4-0FPfF_TcDB7t9yJLz94MM7cPc77dtrMI9-p03O5pc=.45d4d22c-232c-473e-9b15-9d9392c48cfa@github.com>
 <Ne6MShrbDfh8xQbze1nkiz12CS8bu2iUJ2Q81K7xxgo=.5ff9f88b-7e1d-435e-bbb8-a19761b06421@github.com>
Message-ID: <eHpcyAO3EKv_a0ulfsGhwxC5gA0NDe1Z0At_7f0Jrwg=.f3d853f1-c592-433b-aa8a-0199b207d91b@github.com>

On Wed, 28 May 2025 13:40:42 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 34:
>> 
>>> 32:  * @build jdk.httpclient.test.lib.http2.Http2TestServer
>>> 33:  * @run junit HttpClientRetryLimitTest
>>> 34:  * @run junit/othervm -Djdk.httpclient.auth.retrylimit=1 HttpClientRetryLimitTest
>> 
>> @dfuch, shall we test against zero and negative values too? (Both are accepted by `AuthenticationFilter` as valid.)
>
> We could. We could also throw in garbage to see what happens.

New test scenarios have been added in https://github.com/openjdk/jdk/commit/18bac9fa64f81110c2894f5f141e88ec5dc20b03. We have default, positive, zero and negative values.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2114286157

From dclarke at openjdk.org  Wed Jun  4 13:16:18 2025
From: dclarke at openjdk.org (Darragh Clarke)
Date: Wed, 4 Jun 2025 13:16:18 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit
 of 3 retries
In-Reply-To: <Wyr03oYZrq3z6b6tb1Wv_YEPHkyXAK3qB3iamhnFNz8=.9a02744a-1373-4834-b488-d201e9fff501@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
 <Wyr03oYZrq3z6b6tb1Wv_YEPHkyXAK3qB3iamhnFNz8=.9a02744a-1373-4834-b488-d201e9fff501@github.com>
Message-ID: <0SU8NcW9k69ItdVQnpm03vHFyfyVAuPXnpoNXfUNEP4=.96272fae-273d-4ce3-b3da-511aa23680c7@github.com>

On Wed, 28 May 2025 12:04:31 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> 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.
>
> test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 52:
> 
>> 50: 
>> 51:     private static final int DEFAULT_RETRY_LIMIT = 3;
>> 52:     private final int retryLimit = Integer.getInteger("jdk.httpclient.auth.retrylimit", DEFAULT_RETRY_LIMIT);
> 
> Nit: This feels a bit confusing to me when reading it the first time, why not have a retry limit of 1 or 0 as a default and then specify if you want more retries in `@test`?
> I think it might be a bit easier to read, but if you want to keep it, it's fine with me.

This line is grabbing the value of the `jdk.httpclient.auth.retrylimit` system property, and if it hasn't been set then it defaults to 3. This is based on [AuthenticationFilter.java](https://github.com/openjdk/jdk/blob/e89aa7c712be8e576b640a123da52e7f4f5f9391/src/java.net.http/share/classes/jdk/internal/net/http/AuthenticationFilter.java#L57)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2112017438

From duke at openjdk.org  Wed Jun  4 13:16:18 2025
From: duke at openjdk.org (p-nima)
Date: Wed, 4 Jun 2025 13:16:18 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit
 of 3 retries
In-Reply-To: <4-0FPfF_TcDB7t9yJLz94MM7cPc77dtrMI9-p03O5pc=.45d4d22c-232c-473e-9b15-9d9392c48cfa@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
 <4-0FPfF_TcDB7t9yJLz94MM7cPc77dtrMI9-p03O5pc=.45d4d22c-232c-473e-9b15-9d9392c48cfa@github.com>
Message-ID: <ooBprzJJflRvEZVDBbK--xsah9LoZNiPXR0B8EgZZoM=.225daec5-4476-4474-b1ea-00668773fdaa@github.com>

On Wed, 28 May 2025 12:16:02 GMT, Volkan Yazici <vyazici at openjdk.org> 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.
>
> test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 49:
> 
>> 47: import static jdk.test.lib.Asserts.assertEquals;
>> 48: 
>> 49: public class HttpClientRetryLimitTest implements HttpServerAdapters {
> 
> *Nit:* [JUnit recommends the following](https://junit.org/junit5/docs/snapshot/user-guide/#writing-tests-classes-and-methods)
>> It is generally recommended to omit the public modifier for test classes, test methods, and lifecycle methods unless there is a technical reason for doing so ...

Thank you for your feedback. The public modifier has been discarded in 18bac9fa64f81110c2894f5f141e88ec5dc20b03

> test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 52:
> 
>> 50: 
>> 51:     private static final int DEFAULT_RETRY_LIMIT = 3;
>> 52:     private final int retryLimit = Integer.getInteger("jdk.httpclient.auth.retrylimit", DEFAULT_RETRY_LIMIT);
> 
> This can be `static` too.

Updated this in https://github.com/openjdk/jdk/commit/18bac9fa64f81110c2894f5f141e88ec5dc20b03

> test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 53:
> 
>> 51:     private static final int DEFAULT_RETRY_LIMIT = 3;
>> 52:     private final int retryLimit = Integer.getInteger("jdk.httpclient.auth.retrylimit", DEFAULT_RETRY_LIMIT);
>> 53:     private int countRetries;
> 
> This should better be converted to a local variable.

Discarded the above local variable and introduced a AtomicInteger variable in  18bac9fa64f81110c2894f5f141e88ec5dc20b03

> test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 66:
> 
>> 64:             };
>> 65: 
>> 66:             httpTestServer.addHandler(httpTestHandler, "/");
> 
> In the past, there has been occasions in CI where a test server received connections from a totally unrelated test running in parallel on the same host. To avoid such mishaps, we better salt the path a bit by, say, appending the class' simple name?

Thanks for the catch - the class simple name has been appended in 18bac9fa64f81110c2894f5f141e88ec5dc20b03

> test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 69:
> 
>> 67:             httpTestServer.start();
>> 68: 
>> 69:             countRetries = 0;
> 
> IMHO, this should be an `Atomic{Integer,Long}` due to the possibility of concurrent updates.

Agreed. This has been updated in 18bac9fa64f81110c2894f5f141e88ec5dc20b03

> test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 87:
> 
>> 85:                         .build();
>> 86: 
>> 87:                 client.send(request, HttpResponse.BodyHandlers.ofString());
> 
> Since we're not interested in the response, `BodyHandlers.discarding()` might be a better fit here.

Updated this in 18bac9fa64f81110c2894f5f141e88ec5dc20b03

> test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 92:
> 
>> 90:                         "Expected number of retries was " + retryLimit + " but actual was "+countRetries);
>> 91:                 e.printStackTrace();
>> 92:             }
> 
> AFAIU, you should
> 
> 1. Wrap `client::send` with `assertThrows`
> 2. Verify the returned exception
> 1. Then `assertEquals` the retry count
> 
> Otherwise, if `client::send` _unexpectedly_ doesn't throw anything, your test will incorrectly succeed.

Yes, agreed - the changes have been made in 18bac9fa64f81110c2894f5f141e88ec5dc20b03

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2114266126
PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2114275602
PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2114269419
PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2114274151
PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2114270266
PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2114274886
PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2114298224

From duke at openjdk.org  Wed Jun  4 13:16:18 2025
From: duke at openjdk.org (p-nima)
Date: Wed, 4 Jun 2025 13:16:18 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit
 of 3 retries
In-Reply-To: <0SU8NcW9k69ItdVQnpm03vHFyfyVAuPXnpoNXfUNEP4=.96272fae-273d-4ce3-b3da-511aa23680c7@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
 <Wyr03oYZrq3z6b6tb1Wv_YEPHkyXAK3qB3iamhnFNz8=.9a02744a-1373-4834-b488-d201e9fff501@github.com>
 <0SU8NcW9k69ItdVQnpm03vHFyfyVAuPXnpoNXfUNEP4=.96272fae-273d-4ce3-b3da-511aa23680c7@github.com>
Message-ID: <cWJDpK3Lt6VnxM0R5bWiCX1ZkN8VaHZqdah88cJqxT4=.73917af7-1e89-4d52-bbf0-60c419998be5@github.com>

On Wed, 28 May 2025 14:07:37 GMT, Darragh Clarke <dclarke at openjdk.org> wrote:

>> test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 52:
>> 
>>> 50: 
>>> 51:     private static final int DEFAULT_RETRY_LIMIT = 3;
>>> 52:     private final int retryLimit = Integer.getInteger("jdk.httpclient.auth.retrylimit", DEFAULT_RETRY_LIMIT);
>> 
>> Nit: This feels a bit confusing to me when reading it the first time, why not have a retry limit of 1 or 0 as a default and then specify if you want more retries in `@test`?
>> I think it might be a bit easier to read, but if you want to keep it, it's fine with me.
>
> This line is grabbing the value of the `jdk.httpclient.auth.retrylimit` system property, and if it hasn't been set then it defaults to 3. This is based on [AuthenticationFilter.java](https://github.com/openjdk/jdk/blob/e89aa7c712be8e576b640a123da52e7f4f5f9391/src/java.net.http/share/classes/jdk/internal/net/http/AuthenticationFilter.java#L57)

A comment has been added for it in cdf78127351df62193e0ec5a09851de1c32e16e2

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2114263430

From vyazici at openjdk.org  Wed Jun  4 13:16:18 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 4 Jun 2025 13:16:18 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit
 of 3 retries
In-Reply-To: <ooBprzJJflRvEZVDBbK--xsah9LoZNiPXR0B8EgZZoM=.225daec5-4476-4474-b1ea-00668773fdaa@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
 <4-0FPfF_TcDB7t9yJLz94MM7cPc77dtrMI9-p03O5pc=.45d4d22c-232c-473e-9b15-9d9392c48cfa@github.com>
 <ooBprzJJflRvEZVDBbK--xsah9LoZNiPXR0B8EgZZoM=.225daec5-4476-4474-b1ea-00668773fdaa@github.com>
Message-ID: <QrTazuz_2aqwxddzqYiU_-alxsP4DW-yorOOHln2vJw=.db35b4dc-86a4-46b9-8c16-fc20b392ef3e@github.com>

On Thu, 29 May 2025 16:03:11 GMT, p-nima <duke at openjdk.org> wrote:

>> test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 66:
>> 
>>> 64:             };
>>> 65: 
>>> 66:             httpTestServer.addHandler(httpTestHandler, "/");
>> 
>> In the past, there has been occasions in CI where a test server received connections from a totally unrelated test running in parallel on the same host. To avoid such mishaps, we better salt the path a bit by, say, appending the class' simple name?
>
> Thanks for the catch - the class simple name has been appended in 18bac9fa64f81110c2894f5f141e88ec5dc20b03

@p-nima, the handler still accepts all calls to `/`, you only salted the request URI. Would you mind doing the same in `httpTestServer.addHandler(...)` too, please? (You better create a `String requestPath` variable and use it both at the handler and the request.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2115448674

From michaelm at openjdk.org  Wed Jun  4 13:31:11 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 4 Jun 2025 13:31:11 GMT
Subject: RFR: 8351983: HttpCookie Parser Incorrectly Handles Cookies with
 Expires Attribute
Message-ID: <ciW08mWc__2KkinLshBblHOPcHNur3XRpjm8NmFKhg0=.d6a2998f-b16b-4014-a167-c710a8fba107@github.com>

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

-------------

Commit messages:
 - whitespace
 - update
 - impl and test + doc update
 - Merge branch 'master' into cookie-8351983
 - doc update
 - further doc update
 - doc update only

Changes: https://git.openjdk.org/jdk/pull/25636/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25636&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351983
  Stats: 153 lines in 2 files changed: 126 ins; 24 del; 3 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

From dfuchs at openjdk.org  Wed Jun  4 13:49:56 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 4 Jun 2025 13:49:56 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit
 of 3 retries
In-Reply-To: <QrTazuz_2aqwxddzqYiU_-alxsP4DW-yorOOHln2vJw=.db35b4dc-86a4-46b9-8c16-fc20b392ef3e@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
 <4-0FPfF_TcDB7t9yJLz94MM7cPc77dtrMI9-p03O5pc=.45d4d22c-232c-473e-9b15-9d9392c48cfa@github.com>
 <ooBprzJJflRvEZVDBbK--xsah9LoZNiPXR0B8EgZZoM=.225daec5-4476-4474-b1ea-00668773fdaa@github.com>
 <QrTazuz_2aqwxddzqYiU_-alxsP4DW-yorOOHln2vJw=.db35b4dc-86a4-46b9-8c16-fc20b392ef3e@github.com>
Message-ID: <0C_sJwloPs7L7VPd4UpmVUTJaYt2MBFY34kikdMZvh4=.3409bced-ec41-4ff2-ba15-6d5ee97d95f4@github.com>

On Fri, 30 May 2025 08:57:47 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Thanks for the catch - the class simple name has been appended in 18bac9fa64f81110c2894f5f141e88ec5dc20b03
>
> @p-nima, the handler still accepts all calls to `/`, you only salted the request URI. Would you mind doing the same in `httpTestServer.addHandler(...)` too, please? (You better create a `String requestPath` variable and use it both at the handler and the request.)

Yes - this line needs to be modified too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2126651002

From dfuchs at openjdk.org  Wed Jun  4 14:27:51 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 4 Jun 2025 14:27:51 GMT
Subject: RFR: 8351983: HttpCookie Parser Incorrectly Handles Cookies with
 Expires Attribute
In-Reply-To: <ciW08mWc__2KkinLshBblHOPcHNur3XRpjm8NmFKhg0=.d6a2998f-b16b-4014-a167-c710a8fba107@github.com>
References: <ciW08mWc__2KkinLshBblHOPcHNur3XRpjm8NmFKhg0=.d6a2998f-b16b-4014-a167-c710a8fba107@github.com>
Message-ID: <1PtbkKsE2x1KuF8X43mXZXuwfvHb5jKRa2qWultBqBw=.343937c8-728e-4c90-a75e-e970f8a105d1@github.com>

On Wed, 4 Jun 2025 11:12:02 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> 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

LGTM. A minor suggestion for the test.

test/jdk/java/net/HttpCookie/MaxAgeExpires.java line 67:

> 65:         new Test(-1, "Thu, 01 Jan 2024 00:00:00 GMT", 0, true),
> 66:         new Test(1000, "Thu, 01 Jan 2024 00:00:00 GMT", 1000, false),
> 67:         new Test(0, "Thu, 01 Jan 2024 00:00:00 GMT", 0, true),

Maybe you could add a test case with maxAge=1000 and expires = set at the current time + 500s. The expected maxAge would be 1000.

Something like:


static final String NOW_PLUS_500 =
    DateTimeFormatter.RFC_1123_DATE_TIME.format(
        java.time.ZonedDateTime.ofInstant(Instant.now().plusSeconds(500), ZoneId.of("UTC")));

...


    new Test(1000, NOW_PLUS_500, 1000, false),


Ideally we'd like to test the same with maxAge = -1, but that could be tricky since we can't know in advance the exact value that will be computed for the new `maxAge`.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25636#pullrequestreview-2896962645
PR Review Comment: https://git.openjdk.org/jdk/pull/25636#discussion_r2126738975

From alanb at openjdk.org  Wed Jun  4 14:35:00 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 4 Jun 2025 14:35:00 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v3]
In-Reply-To: <DbxABSmBFyo8jlTL2jMdq-60DALxvrASNGrzVTzJRyQ=.a5452f1a-6144-452c-bec1-61e08f2548c0@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <DbxABSmBFyo8jlTL2jMdq-60DALxvrASNGrzVTzJRyQ=.a5452f1a-6144-452c-bec1-61e08f2548c0@github.com>
Message-ID: <7i52AKYBlYgN9kWre2Nc7gUusKWjRJ3aQD8sll095xg=.c2589f2d-76c6-405a-92ab-2b33908c9cc1@github.com>

On Tue, 3 Jun 2025 12:50:49 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
>> 
>> Testing: test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix adjust boundary

src/java.base/share/classes/java/net/Socket.java line 970:

> 968:             long end = SocketReadEvent.timestamp();
> 969:             long duration = end - start;
> 970:             if (SocketReadEvent.shouldThrottleCommit(duration, end)) {

The use sites want to ask if an event should be committed. Does the word "Throttle" need to be in name as I don't think the use cases need to care about this.

Also,  just to point out that the shouldXXX method is called with the the end timestamp and duration whereas the offset/emit/commit methods are called with the start timestamp and duration. So two long timestamps and a long measure of time, easy to get it wrong somewhere. Maybe not this PR but I think would be clearer at the use sites to use start or end consistently and reduce potential for mistakes.

src/jdk.jfr/share/classes/jdk/jfr/Throttle.java line 77:

> 75:      * Specifying {@code "off"} (case-sensitive) results in all events being emitted.
> 76:      *
> 77:      * @return the throttle value, default {@code "off"} not {@code null}

I think it would be clear to drop "not null" from the return description.

src/jdk.jfr/share/conf/jfr/default.jfc line 762:

> 760:       <setting name="enabled">true</setting>
> 761:       <setting name="stackTrace">true</setting>
> 762:       <setting name="threshold">20 ms</setting>

I agree FileForce isn't a good candidate to throttle.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2126765474
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2126722810
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2126719134

From dfuchs at openjdk.org  Wed Jun  4 15:46:36 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 4 Jun 2025 15:46:36 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v6]
In-Reply-To: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
Message-ID: <VLxUS3uO-15BM72IayGCOFsuDVbfjLhF00V_1M0ObmI=.b93005af-4d6b-4aa4-a30c-9eb41efdc048@github.com>

> Hi,
> 
> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
> 
> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
> 
> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.

Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 495 commits:

 - merge latest changes from master branch
 - http3: fix bug introduced by Http3ConnectionPool and improved debug logs
 - http3: refactor HTTP/3 connection pool management in a separate class
 - Ignore DestroyFailedExceptions
 - Remove outdated TODO
 - Remove outdated TODO
 - Remove cryptic TODO
 - Remove outdated TODO
 - Fix race in test server's Http3StreamDispatcher
 - Test H3 server: close connection if control stream closed
 - ... and 485 more: https://git.openjdk.org/jdk/compare/7838321b...a41217f0

-------------

Changes: https://git.openjdk.org/jdk/pull/24751/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24751&range=05
  Stats: 103642 lines in 473 files changed: 100781 ins; 1345 del; 1516 mod
  Patch: https://git.openjdk.org/jdk/pull/24751.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24751/head:pull/24751

PR: https://git.openjdk.org/jdk/pull/24751

From egahlin at openjdk.org  Wed Jun  4 15:59:03 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 4 Jun 2025 15:59:03 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v3]
In-Reply-To: <7i52AKYBlYgN9kWre2Nc7gUusKWjRJ3aQD8sll095xg=.c2589f2d-76c6-405a-92ab-2b33908c9cc1@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <DbxABSmBFyo8jlTL2jMdq-60DALxvrASNGrzVTzJRyQ=.a5452f1a-6144-452c-bec1-61e08f2548c0@github.com>
 <7i52AKYBlYgN9kWre2Nc7gUusKWjRJ3aQD8sll095xg=.c2589f2d-76c6-405a-92ab-2b33908c9cc1@github.com>
Message-ID: <wJSneY7Iw7SjTULCVaLikMyjKH7L9q5sn4ZuAQcx8lA=.15ec6ced-d662-474b-99a1-b7937c7ceb68@github.com>

On Wed, 4 Jun 2025 14:16:56 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix adjust boundary
>
> src/jdk.jfr/share/classes/jdk/jfr/Throttle.java line 77:
> 
>> 75:      * Specifying {@code "off"} (case-sensitive) results in all events being emitted.
>> 76:      *
>> 77:      * @return the throttle value, default {@code "off"} not {@code null}
> 
> I think it would be clearer to drop "not null" from the return description.

We have "not null" with Threshold, but not with "Period". I filed a bug to make it consistent for all JFR annotations and I can bring Throttle into the same CSR. 

https://bugs.openjdk.org/browse/JDK-8358602

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2126946237

From egahlin at openjdk.org  Wed Jun  4 16:06:55 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 4 Jun 2025 16:06:55 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v3]
In-Reply-To: <7i52AKYBlYgN9kWre2Nc7gUusKWjRJ3aQD8sll095xg=.c2589f2d-76c6-405a-92ab-2b33908c9cc1@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <DbxABSmBFyo8jlTL2jMdq-60DALxvrASNGrzVTzJRyQ=.a5452f1a-6144-452c-bec1-61e08f2548c0@github.com>
 <7i52AKYBlYgN9kWre2Nc7gUusKWjRJ3aQD8sll095xg=.c2589f2d-76c6-405a-92ab-2b33908c9cc1@github.com>
Message-ID: <2s1MhHmV6w6DgtZEIQ056jvOQDG4SxfDNXgf_H31RZA=.2f0f2395-f805-41be-85bc-7cb4e1a8a0a9@github.com>

On Wed, 4 Jun 2025 14:32:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix adjust boundary
>
> src/java.base/share/classes/java/net/Socket.java line 970:
> 
>> 968:             long end = SocketReadEvent.timestamp();
>> 969:             long duration = end - start;
>> 970:             if (SocketReadEvent.shouldThrottleCommit(duration, end)) {
> 
> The use sites want to ask if an event should be committed. Does the word "Throttle" need to be in name as I don't think the use cases need to care about this.
> 
> Also,  just to point out that the shouldXXX method is called with the the end timestamp and duration whereas the offset/emit/commit methods are called with the start timestamp and duration. So two long timestamps and a long measure of time, easy to get it wrong somewhere. Maybe not this PR but I think would be clearer at the use sites to use start or end consistently and reduce potential for mistakes.

We need some indication of which events are throttleable and looking at the mirror event may not work in some scenarios.

We need to sample the endTime, because the startTime may be several minutes in the past. We could use commit(startTime, endTime, ...) and calculate the duration inside the method, but it may be confusing because the fields in the event are startTime and duration. We would also need to calculate the duration twice, both for shouldCommit and commit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2126960704

From dfuchs at openjdk.org  Wed Jun  4 16:08:04 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 4 Jun 2025 16:08:04 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v5]
In-Reply-To: <t01ZejGn4WMUYiK_2xMiWTgI-gtY6BOEsix4cOxKESA=.4ae87c30-da46-4e5c-9094-b676d4c38f4b@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <l0kZnNDdN-TbltTkaEW4yohiocDPHWvIJu34Nl8em8g=.02e58472-5252-414f-bfa6-9c06af35d5b6@github.com>
 <t01ZejGn4WMUYiK_2xMiWTgI-gtY6BOEsix4cOxKESA=.4ae87c30-da46-4e5c-9094-b676d4c38f4b@github.com>
Message-ID: <UngOa-uQ8FF4qZk_AdQcyxqGWy_EsLCwDJDFv7MQqMQ=.a822c514-86df-452a-b63a-2716cc50b238@github.com>

On Fri, 16 May 2025 10:26:11 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 422 commits:
>> 
>>  - merge latest changes from master branch
>>  - Undo whitespace change
>>  - Remove unnecessary import
>>  - Merge remote-tracking branch 'origin/master' into http3
>>  - Fix test license
>>  - Remove leftover file (test was moved to parent directory)
>>  - Remove unnecessary import
>>  - Update throws clauses
>>  - Merge remote-tracking branch 'origin/master' into http3
>>  - 8354275: Add HTTP/3 tests to `EmptyAuthenticate`
>>  - ... and 412 more: https://git.openjdk.org/jdk/compare/568dcc15...8c27f53c
>
> src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicEndpoint.java line 737:
> 
>> 735:         // channel, and a single selector thread, so we can do
>> 736:         // the reading directly in the selector thread and offload
>> 737:         // the parsing (the readLoop) to the executor.
> 
> This comment is outdated. We actually stop reading from the channel when the amount of data buffered exceeds a high watermark threshold.

Updated in latest commits (https://github.com/openjdk/jdk/pull/24751/commits/6ce42f44c52c5b6db54ccceb4f62259cb02992fb)

> src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicEndpoint.java line 822:
> 
>> 820:                     if (this.buffered.get() >= MAX_BUFFERED_HIGH) {
>> 821:                         pauseReading();
>> 822:                         readLoopScheduler.runOrSchedule(executor);
> 
> This line should not be needed: we should already have kicked the read loop at line 797.

Updated in latest commits (https://github.com/openjdk/jdk/pull/24751/commits/6ce42f44c52c5b6db54ccceb4f62259cb02992fb)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2126958527
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2126959414

From dfuchs at openjdk.org  Wed Jun  4 17:54:25 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 4 Jun 2025 17:54:25 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v6]
In-Reply-To: <VLxUS3uO-15BM72IayGCOFsuDVbfjLhF00V_1M0ObmI=.b93005af-4d6b-4aa4-a30c-9eb41efdc048@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
 <VLxUS3uO-15BM72IayGCOFsuDVbfjLhF00V_1M0ObmI=.b93005af-4d6b-4aa4-a30c-9eb41efdc048@github.com>
Message-ID: <ilp-dq4Sz3lLQs-v9R-04shh7tKsaQLPBts7z5VO0zQ=.9c6aa5c9-357f-43c2-9481-e54e01f48ce4@github.com>

On Wed, 4 Jun 2025 15:46:36 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
>> 
>> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
>> 
>> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
>> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 495 commits:
> 
>  - merge latest changes from master branch
>  - http3: fix bug introduced by Http3ConnectionPool and improved debug logs
>  - http3: refactor HTTP/3 connection pool management in a separate class
>  - Ignore DestroyFailedExceptions
>  - Remove outdated TODO
>  - Remove outdated TODO
>  - Remove cryptic TODO
>  - Remove outdated TODO
>  - Fix race in test server's Http3StreamDispatcher
>  - Test H3 server: close connection if control stream closed
>  - ... and 485 more: https://git.openjdk.org/jdk/compare/7838321b...a41217f0

src/java.net.http/share/classes/jdk/internal/net/http/hpack/HPACK.java line 176:

> 174: 
> 175:     @FunctionalInterface
> 176:     interface BufferUpdateConsumer {

@AlekseiEfimov It looks like this change is no longer required and could be reverted

src/java.net.http/share/classes/jdk/internal/net/http/hpack/ISO_8859_1.java line 43:

> 41: // The encoding is simple and well known: 1 byte <-> 1 char
> 42: //
> 43: final class ISO_8859_1 {

OK - this class is actually used in QPack as well as HPack. Same for the `QuickHuffman` class below (notice that this is Quick - not Quic ;-) )

It might be interesting to investigate if we could pull out these classes to a common location to break the tie between QPack and HPack. Something to think about after integration maybe.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2126966393
PR Review Comment: https://git.openjdk.org/jdk/pull/24751#discussion_r2127123043

From smarks at openjdk.org  Thu Jun  5 00:24:55 2025
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 5 Jun 2025 00:24:55 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v3]
In-Reply-To: <2s1MhHmV6w6DgtZEIQ056jvOQDG4SxfDNXgf_H31RZA=.2f0f2395-f805-41be-85bc-7cb4e1a8a0a9@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <DbxABSmBFyo8jlTL2jMdq-60DALxvrASNGrzVTzJRyQ=.a5452f1a-6144-452c-bec1-61e08f2548c0@github.com>
 <7i52AKYBlYgN9kWre2Nc7gUusKWjRJ3aQD8sll095xg=.c2589f2d-76c6-405a-92ab-2b33908c9cc1@github.com>
 <2s1MhHmV6w6DgtZEIQ056jvOQDG4SxfDNXgf_H31RZA=.2f0f2395-f805-41be-85bc-7cb4e1a8a0a9@github.com>
Message-ID: <UTGl8Bkt5sB4NW77bhZVWQGE4xN7a0MCXjhVn5k_wnk=.b1ff279d-f5b4-45f3-94a7-4aad266878d1@github.com>

On Wed, 4 Jun 2025 16:04:08 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> src/java.base/share/classes/java/net/Socket.java line 970:
>> 
>>> 968:             long end = SocketReadEvent.timestamp();
>>> 969:             long duration = end - start;
>>> 970:             if (SocketReadEvent.shouldThrottleCommit(duration, end)) {
>> 
>> The use sites want to ask if an event should be committed. Does the word "Throttle" need to be in name as I don't think the use cases need to care about this.
>> 
>> Also,  just to point out that the shouldXXX method is called with the the end timestamp and duration whereas the offset/emit/commit methods are called with the start timestamp and duration. So two long timestamps and a long measure of time, easy to get it wrong somewhere. Maybe not this PR but I think would be clearer at the use sites to use start or end consistently and reduce potential for mistakes.
>
> We need some indication of which events are throttleable and looking at the mirror event may not work in some scenarios.
> 
> We need to sample the endTime, because the startTime may be several minutes in the past. We could use commit(startTime, endTime, ...) and calculate the duration inside the method, but it may be confusing because the fields in the event are startTime and duration. We would also need to calculate the duration twice, both for shouldCommit and commit.
> 
> When we get value types and perhaps value events, much of the ugliness of static methods could be avoided.

I think we (from both the java.base and jdk.jfr perspectives) need to keep an eye on the complexity of the use sites. The new throttling stuff requires a new local variable. By itself this isn't a big deal, but there are 12 events being updated here. In addition, each requires a start, end, and duration, and clearly duration = end - start. These are all long values, and the different calls require different long values, so sooner or later somebody is going to get this wrong.

To a certain extent we can do more cleanup on the java.base side, by using things like SocketReadEvent's offer() method instead of its emit() method. Unfortunately only one site uses offer() -- NIO SocketChannelImpl -- and note that it didn't need to be updated! The other events should have something like the offer() method, which groups together the testing of shouldCommit/shouldThrottleCommit with the committing of the event. (This also should avoid recalculating the duration, but really, this is only a subtraction of two longs, so it should take only one cycle.)

But note what we're doing here is constructing an internal API within java.base, between the use sites (like java.net.Socket) and the java.base-side JFR stuff (jdk.internal.event.SocketReadEvent). Maybe after things are cleaned up and consolidated here we can see if the API between jdk.internal.event and jdk.jfr can be improved.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2127716516

From vyazici at openjdk.org  Thu Jun  5 05:36:50 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 5 Jun 2025 05:36:50 GMT
Subject: RFR: 8351983: HttpCookie Parser Incorrectly Handles Cookies with
 Expires Attribute
In-Reply-To: <ciW08mWc__2KkinLshBblHOPcHNur3XRpjm8NmFKhg0=.d6a2998f-b16b-4014-a167-c710a8fba107@github.com>
References: <ciW08mWc__2KkinLshBblHOPcHNur3XRpjm8NmFKhg0=.d6a2998f-b16b-4014-a167-c710a8fba107@github.com>
Message-ID: <k9TT7coEMpzPZqYQYYCwY4MB5XxmLnYngD8EpmVqefA=.a29c26ef-0883-4911-91b2-fbb1168ef4f2@github.com>

On Wed, 4 Jun 2025 11:12:02 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> 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

src/java.base/share/classes/java/net/HttpCookie.java line 1:

> 1: /*

Copyright year needs to be updated.

test/jdk/java/net/HttpCookie/MaxAgeExpires.java line 27:

> 25:  * @test
> 26:  * @bug 8351983
> 27:  * @summary HttpCookie Parser Incorrectly Handles Cookies with Expires Attribute

Aren't we missing a `@run` tag?

test/jdk/java/net/HttpCookie/MaxAgeExpires.java line 63:

> 61:     }
> 62: 
> 63:     static Test[] tests = new Test[] {

*Tip:* JUnit `@ParameterizedTest @CsvSource` can save us some boilerplate here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25636#discussion_r2127988396
PR Review Comment: https://git.openjdk.org/jdk/pull/25636#discussion_r2127987557
PR Review Comment: https://git.openjdk.org/jdk/pull/25636#discussion_r2127987253

From vyazici at openjdk.org  Thu Jun  5 05:36:51 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 5 Jun 2025 05:36:51 GMT
Subject: RFR: 8351983: HttpCookie Parser Incorrectly Handles Cookies with
 Expires Attribute
In-Reply-To: <1PtbkKsE2x1KuF8X43mXZXuwfvHb5jKRa2qWultBqBw=.343937c8-728e-4c90-a75e-e970f8a105d1@github.com>
References: <ciW08mWc__2KkinLshBblHOPcHNur3XRpjm8NmFKhg0=.d6a2998f-b16b-4014-a167-c710a8fba107@github.com>
 <1PtbkKsE2x1KuF8X43mXZXuwfvHb5jKRa2qWultBqBw=.343937c8-728e-4c90-a75e-e970f8a105d1@github.com>
Message-ID: <CiYqkEPrqUFI0pTty0rmfqNhiCai5qzBlLWErW7shsQ=.1781f325-bc7a-4e88-bc6f-4f0e57acdca3@github.com>

On Wed, 4 Jun 2025 14:23:01 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> 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
>
> test/jdk/java/net/HttpCookie/MaxAgeExpires.java line 67:
> 
>> 65:         new Test(-1, "Thu, 01 Jan 2024 00:00:00 GMT", 0, true),
>> 66:         new Test(1000, "Thu, 01 Jan 2024 00:00:00 GMT", 1000, false),
>> 67:         new Test(0, "Thu, 01 Jan 2024 00:00:00 GMT", 0, true),
> 
> Maybe you could add a test case with maxAge=1000 and expires = set at the current time + 500s. The expected maxAge would be 1000.
> 
> Something like:
> 
> 
> static final String NOW_PLUS_500 =
>     DateTimeFormatter.RFC_1123_DATE_TIME.format(
>         java.time.ZonedDateTime.ofInstant(Instant.now().plusSeconds(500), ZoneId.of("UTC")));
> 
> ...
> 
> 
>     new Test(1000, NOW_PLUS_500, 1000, false),
> 
> 
> Ideally we'd like to test the same with maxAge = -1, but that could be tricky since we can't know in advance the exact value that will be computed for the new `maxAge`.

Alternatively, we could create a `HttpCookie::parse` method<sup>1</sup> accepting a `long currentTimeMillis`, and precisely determine the expected value?

<sup>1</sup> This can either be private and accessed via reflection, or package-private and accessed by placing the test in the same package.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25636#discussion_r2127986120

From egahlin at openjdk.org  Thu Jun  5 08:10:42 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 5 Jun 2025 08:10:42 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v4]
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <72MCuwD8Jd9igYMm5C4yZyxh-8xLnnKePImAaep3p2U=.49745a1b-7f46-4a07-a150-4c243683068f@github.com>

> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

Erik Gahlin 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 seven additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into throttle-mania-3
 - Fix adjust boundary
 - Some reviewer feedback
 - Consistent annotation
 - Fix typos
 - Fix whitespace
 - Initial

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25559/files
  - new: https://git.openjdk.org/jdk/pull/25559/files/7fa2db19..59278ca8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25559&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25559&range=02-03

  Stats: 26802 lines in 553 files changed: 20626 ins; 2170 del; 4006 mod
  Patch: https://git.openjdk.org/jdk/pull/25559.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25559/head:pull/25559

PR: https://git.openjdk.org/jdk/pull/25559

From egahlin at openjdk.org  Thu Jun  5 08:13:21 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 5 Jun 2025 08:13:21 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v5]
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <8opPh4lTfGQBzlleDOuxmi3QyhF3M9M7U7MpIoFWUCE=.a14d1385-e759-4fa5-8733-5ebb162d20a7@github.com>

> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

Erik Gahlin 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 eight additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into throttle-mania-3
 - Merge remote-tracking branch 'upstream/master' into throttle-mania-3
 - Fix adjust boundary
 - Some reviewer feedback
 - Consistent annotation
 - Fix typos
 - Fix whitespace
 - Initial

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25559/files
  - new: https://git.openjdk.org/jdk/pull/25559/files/59278ca8..535d458a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25559&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25559&range=03-04

  Stats: 2776 lines in 58 files changed: 477 ins; 2217 del; 82 mod
  Patch: https://git.openjdk.org/jdk/pull/25559.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25559/head:pull/25559

PR: https://git.openjdk.org/jdk/pull/25559

From egahlin at openjdk.org  Thu Jun  5 08:40:44 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 5 Jun 2025 08:40:44 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v6]
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <0zy-Tz-VxzBeZiq5EE1iHvG-Z5pmhyByw6H3aCD2Mm4=.217bcfc4-f471-48cc-a003-22bcda24669d@github.com>

> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

Erik Gahlin 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 nine additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into throttle-mania-3
 - Merge remote-tracking branch 'upstream/master' into throttle-mania-3
 - Merge remote-tracking branch 'upstream/master' into throttle-mania-3
 - Fix adjust boundary
 - Some reviewer feedback
 - Consistent annotation
 - Fix typos
 - Fix whitespace
 - Initial

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25559/files
  - new: https://git.openjdk.org/jdk/pull/25559/files/535d458a..8259ff41

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25559&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25559&range=04-05

  Stats: 2319 lines in 41 files changed: 2179 ins; 128 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/25559.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25559/head:pull/25559

PR: https://git.openjdk.org/jdk/pull/25559

From aturbanov at openjdk.org  Thu Jun  5 09:02:57 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 5 Jun 2025 09:02:57 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v6]
In-Reply-To: <0zy-Tz-VxzBeZiq5EE1iHvG-Z5pmhyByw6H3aCD2Mm4=.217bcfc4-f471-48cc-a003-22bcda24669d@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <0zy-Tz-VxzBeZiq5EE1iHvG-Z5pmhyByw6H3aCD2Mm4=.217bcfc4-f471-48cc-a003-22bcda24669d@github.com>
Message-ID: <bPhyUNuWlTSgWzVu0XGymtuPwYZa2VqhcLPb7siVcmU=.60458892-b041-4fa8-8237-094f995e50c6@github.com>

On Thu, 5 Jun 2025 08:40:44 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
>> 
>> Testing: test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin 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 nine additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into throttle-mania-3
>  - Merge remote-tracking branch 'upstream/master' into throttle-mania-3
>  - Merge remote-tracking branch 'upstream/master' into throttle-mania-3
>  - Fix adjust boundary
>  - Some reviewer feedback
>  - Consistent annotation
>  - Fix typos
>  - Fix whitespace
>  - Initial

src/java.base/share/classes/java/io/RandomAccessFile.java line 594:

> 592:         } finally {
> 593:             long end = FileWriteEvent.timestamp();
> 594:             long duration =  end - start;

Suggestion:

            long duration = end - start;

src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 65:

> 63: public final class EventInstrumentation {
> 64:     public static final long MASK_THROTTLE              = 1 << 62;
> 65:     public static final long MASK_THROTTLE_CHECK        = 1 << 63;

Let's align
Suggestion:

    public static final long MASK_THROTTLE               = 1 << 62;
    public static final long MASK_THROTTLE_CHECK         = 1 << 63;

src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 593:

> 591:         if (throttled) {
> 592:             codeBuilder.aload(0);
> 593:             getfield(codeBuilder, eventClassDesc,  ImplicitFields.FIELD_DURATION);

Suggestion:

            getfield(codeBuilder, eventClassDesc, ImplicitFields.FIELD_DURATION);

test/jdk/jdk/jfr/api/recording/settings/TestSettingsAvailability.java line 93:

> 91:         testSetting(EventNames.JVMInformation, "enabled", "period");
> 92:         testSetting(EventNames.FileRead, "enabled", "threshold", "stackTrace", "throttle");
> 93:         testSetting(EventNames.FileWrite, "enabled", "threshold","stackTrace", "throttle");

Suggestion:

        testSetting(EventNames.FileWrite, "enabled", "threshold", "stackTrace", "throttle");

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128322876
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128321445
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128322474
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128323708

From egahlin at openjdk.org  Thu Jun  5 09:26:13 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 5 Jun 2025 09:26:13 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v7]
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <nf8lATfmGhbu9fh-ojvo7nnxJnONoa42lBlCJxTwLLc=.5fed0134-cff8-46d4-9ebd-0c14425801ba@github.com>

> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:

  Use offer method

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25559/files
  - new: https://git.openjdk.org/jdk/pull/25559/files/8259ff41..7f26f172

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25559&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25559&range=05-06

  Stats: 570 lines in 10 files changed: 455 ins; 88 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/25559.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25559/head:pull/25559

PR: https://git.openjdk.org/jdk/pull/25559

From alanb at openjdk.org  Thu Jun  5 09:28:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Jun 2025 09:28:52 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v7]
In-Reply-To: <nf8lATfmGhbu9fh-ojvo7nnxJnONoa42lBlCJxTwLLc=.5fed0134-cff8-46d4-9ebd-0c14425801ba@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <nf8lATfmGhbu9fh-ojvo7nnxJnONoa42lBlCJxTwLLc=.5fed0134-cff8-46d4-9ebd-0c14425801ba@github.com>
Message-ID: <g4wakHQv7Fsl1YNLYTUXAPUC7WwQb7CM3wV9FrJMNYs=.b91f4a96-a4ec-4bd2-9ddc-67409d4097b4@github.com>

On Thu, 5 Jun 2025 09:26:13 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
>> 
>> Testing: test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use offer method

t.txt line 1:

> 1: diff --git a/src/java.base/share/classes/java/io/FileInputStream.java b/src/java.base/share/classes/java/io/FileInputStream.java

t.txt added by mistake.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128388583

From egahlin at openjdk.org  Thu Jun  5 09:41:10 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 5 Jun 2025 09:41:10 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v8]
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <C1YJ93tl5cn0qoCtfBvQYbnpKT7gu0yrBDd20V-_LSw=.f9f1e7eb-082c-44c9-85f1-b428dc29dcb3@github.com>

> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

Erik Gahlin has updated the pull request incrementally with two additional commits since the last revision:

 - Remove the mistakenly added file.
 - Fix whitespace

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25559/files
  - new: https://git.openjdk.org/jdk/pull/25559/files/7f26f172..8beb194a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25559&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25559&range=06-07

  Stats: 414 lines in 3 files changed: 0 ins; 410 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/25559.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25559/head:pull/25559

PR: https://git.openjdk.org/jdk/pull/25559

From alanb at openjdk.org  Thu Jun  5 09:41:10 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Jun 2025 09:41:10 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v8]
In-Reply-To: <C1YJ93tl5cn0qoCtfBvQYbnpKT7gu0yrBDd20V-_LSw=.f9f1e7eb-082c-44c9-85f1-b428dc29dcb3@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <C1YJ93tl5cn0qoCtfBvQYbnpKT7gu0yrBDd20V-_LSw=.f9f1e7eb-082c-44c9-85f1-b428dc29dcb3@github.com>
Message-ID: <APXhHhCmSmtSgE7-D_oiy7_DFNdzKqfEdkOmQUkXVMc=.e66a486a-0074-4756-a5d5-903fc4a4cbd0@github.com>

On Thu, 5 Jun 2025 09:37:45 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
>> 
>> Testing: test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove the mistakenly added file.
>  - Fix whitespace

src/java.base/share/classes/java/io/FileInputStream.java line 219:

> 217:             }
> 218:         } finally {
> 219:             FileReadEvent.offer(start, path, bytesRead);

Thanks for this update, this looks much better. It think would be better again if `start = FileReadEvent.timestamp()` is moved to before the try.

src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 328:

> 326:         } finally {
> 327:             long end = FileReadEvent.timestamp();
> 328:             FileReadEvent.offer(start, path, bytesRead);

I don't think "end" is needed now.

src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 382:

> 380:             FileWriteEvent.offer(start, path, bytes);
> 381:         }
> 382:         return bytes;

The method returns the number of bytes written and traceImplRead uses bytesRead for the number of bytes read. So I think better to leave it as bytesWritten.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128400058
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128401565
PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128406420

From egahlin at openjdk.org  Thu Jun  5 09:41:10 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 5 Jun 2025 09:41:10 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v3]
In-Reply-To: <UTGl8Bkt5sB4NW77bhZVWQGE4xN7a0MCXjhVn5k_wnk=.b1ff279d-f5b4-45f3-94a7-4aad266878d1@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <DbxABSmBFyo8jlTL2jMdq-60DALxvrASNGrzVTzJRyQ=.a5452f1a-6144-452c-bec1-61e08f2548c0@github.com>
 <7i52AKYBlYgN9kWre2Nc7gUusKWjRJ3aQD8sll095xg=.c2589f2d-76c6-405a-92ab-2b33908c9cc1@github.com>
 <2s1MhHmV6w6DgtZEIQ056jvOQDG4SxfDNXgf_H31RZA=.2f0f2395-f805-41be-85bc-7cb4e1a8a0a9@github.com>
 <UTGl8Bkt5sB4NW77bhZVWQGE4xN7a0MCXjhVn5k_wnk=.b1ff279d-f5b4-45f3-94a7-4aad266878d1@github.com>
Message-ID: <h88YQpMEwvvo4z9dv7JVCWzKp6PsjSFNIXJ2ECAYQA4=.9adce128-6e5c-49f2-b9d2-21b0f2786008@github.com>

On Thu, 5 Jun 2025 00:21:45 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> We need some indication of which events are throttleable and looking at the mirror event may not work in some scenarios.
>> 
>> We need to sample the endTime, because the startTime may be several minutes in the past. We could use commit(startTime, endTime, ...) and calculate the duration inside the method, but it may be confusing because the fields in the event are startTime and duration. We would also need to calculate the duration twice, both for shouldCommit and commit.
>> 
>> When we get value types and perhaps value events, much of the ugliness of static methods could be avoided.
>
> I think we (from both the java.base and jdk.jfr perspectives) need to keep an eye on the complexity of the use sites. The new throttling stuff requires a new local variable. By itself this isn't a big deal, but there are 12 events being updated here. In addition, each requires a start, end, and duration, and clearly duration = end - start. These are all long values, and the different calls require different long values, so sooner or later somebody is going to get this wrong.
> 
> To a certain extent we can do more cleanup on the java.base side, by using things like SocketReadEvent's offer() method instead of its emit() method. Unfortunately only one site uses offer() -- NIO SocketChannelImpl -- and note that it didn't need to be updated! The other events should have something like the offer() method, which groups together the testing of shouldCommit/shouldThrottleCommit with the committing of the event. (This also should avoid recalculating the duration, but really, this is only a subtraction of two longs, so it should take only one cycle.)
> 
> But note what we're doing here is constructing an internal API within java.base, between the use sites (like java.net.Socket) and the java.base-side JFR stuff (jdk.internal.event.SocketReadEvent). Maybe after things are cleaned up and consolidated here we can see if the API between jdk.internal.event and jdk.jfr can be improved.

I updated FileRead and FileWrite to use an offer method like SocketRead and SocketWrite, reducing boilerplate.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128398824

From alanb at openjdk.org  Thu Jun  5 09:41:10 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Jun 2025 09:41:10 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v3]
In-Reply-To: <h88YQpMEwvvo4z9dv7JVCWzKp6PsjSFNIXJ2ECAYQA4=.9adce128-6e5c-49f2-b9d2-21b0f2786008@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <DbxABSmBFyo8jlTL2jMdq-60DALxvrASNGrzVTzJRyQ=.a5452f1a-6144-452c-bec1-61e08f2548c0@github.com>
 <7i52AKYBlYgN9kWre2Nc7gUusKWjRJ3aQD8sll095xg=.c2589f2d-76c6-405a-92ab-2b33908c9cc1@github.com>
 <2s1MhHmV6w6DgtZEIQ056jvOQDG4SxfDNXgf_H31RZA=.2f0f2395-f805-41be-85bc-7cb4e1a8a0a9@github.com>
 <UTGl8Bkt5sB4NW77bhZVWQGE4xN7a0MCXjhVn5k_wnk=.b1ff279d-f5b4-45f3-94a7-4aad266878d1@github.com>
 <h88YQpMEwvvo4z9dv7JVCWzKp6PsjSFNIXJ2ECAYQA4=.9adce128-6e5c-49f2-b9d2-21b0f2786008@github.com>
Message-ID: <Zwcb_hQVZmXxEiB91eADdb60FeRk8-8g5VfbolZa1FA=.3d4e5d5b-6653-4adc-9c9d-06e06b7d2977@github.com>

On Thu, 5 Jun 2025 09:31:39 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> I think we (from both the java.base and jdk.jfr perspectives) need to keep an eye on the complexity of the use sites. The new throttling stuff requires a new local variable. By itself this isn't a big deal, but there are 12 events being updated here. In addition, each requires a start, end, and duration, and clearly duration = end - start. These are all long values, and the different calls require different long values, so sooner or later somebody is going to get this wrong.
>> 
>> To a certain extent we can do more cleanup on the java.base side, by using things like SocketReadEvent's offer() method instead of its emit() method. Unfortunately only one site uses offer() -- NIO SocketChannelImpl -- and note that it didn't need to be updated! The other events should have something like the offer() method, which groups together the testing of shouldCommit/shouldThrottleCommit with the committing of the event. (This also should avoid recalculating the duration, but really, this is only a subtraction of two longs, so it should take only one cycle.)
>> 
>> But note what we're doing here is constructing an internal API within java.base, between the use sites (like java.net.Socket) and the java.base-side JFR stuff (jdk.internal.event.SocketReadEvent). Maybe after things are cleaned up and consolidated here we can see if the API between jdk.internal.event and jdk.jfr can be improved.
>
> I updated FileRead and FileWrite to use an offer method like SocketRead and SocketWrite, reducing boilerplate.

Thank you for this update, it looks much better now. I chatted briefly with Stuart yesterday and mostly agreed there would need to be some follow-up cleanup of the use-sites. Doing in now is good as it addresses our grumblings.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128410969

From alanb at openjdk.org  Thu Jun  5 09:48:57 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Jun 2025 09:48:57 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v8]
In-Reply-To: <C1YJ93tl5cn0qoCtfBvQYbnpKT7gu0yrBDd20V-_LSw=.f9f1e7eb-082c-44c9-85f1-b428dc29dcb3@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <C1YJ93tl5cn0qoCtfBvQYbnpKT7gu0yrBDd20V-_LSw=.f9f1e7eb-082c-44c9-85f1-b428dc29dcb3@github.com>
Message-ID: <QzDSW4zb1mvKE02K7Lqu-i0ORDvEpXM5AXglPU0MkrM=.8cb32924-10cf-4734-8bef-ca5820d47ac2@github.com>

On Thu, 5 Jun 2025 09:41:10 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
>> 
>> Testing: test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove the mistakenly added file.
>  - Fix whitespace

src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 1252:

> 1250:         } finally {
> 1251:             long bytes = bytesWritten > 0 ? bytesWritten : 0;
> 1252:             FileWriteEvent.offer(start, path, bytes);

The number of bytes written is >=0, it can't be < 0, so I'm not sure why the existing code checks bytesWritten > 0.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128429546

From alanb at openjdk.org  Thu Jun  5 09:54:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Jun 2025 09:54:52 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v8]
In-Reply-To: <C1YJ93tl5cn0qoCtfBvQYbnpKT7gu0yrBDd20V-_LSw=.f9f1e7eb-082c-44c9-85f1-b428dc29dcb3@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <C1YJ93tl5cn0qoCtfBvQYbnpKT7gu0yrBDd20V-_LSw=.f9f1e7eb-082c-44c9-85f1-b428dc29dcb3@github.com>
Message-ID: <AbC0yTXSfxSe_gfV46sAk4L4sfP-eXuvN2j-tXYrQ18=.86ff17dc-b339-4c4f-98b5-b7c555096ce5@github.com>

On Thu, 5 Jun 2025 09:41:10 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
>> 
>> Testing: test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove the mistakenly added file.
>  - Fix whitespace

src/jdk.jfr/share/conf/jfr/default.jfc line 845:

> 843:       <setting name="enabled" control="enable-exceptions">true</setting>
> 844:       <setting name="stackTrace">true</setting>
> 845:       <setting name="throttle" control="exceptions-throttle-rate">100/s</setting>

What was used to proposed 100/s as the default and 300/s in profile.jfc?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128442250

From egahlin at openjdk.org  Thu Jun  5 10:10:41 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 5 Jun 2025 10:10:41 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v9]
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <Y4CrvczNMFqOaYOJheUhfOD8L-c_iKdtAslcS-ygnIg=.7373ce4f-fd1e-4f9a-b785-e0cf61a32566@github.com>

> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:

  Move the timestamp to before the try block, change bytes to bytesWritten and remove unnecessary code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25559/files
  - new: https://git.openjdk.org/jdk/pull/25559/files/8beb194a..45adc081

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25559&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25559&range=07-08

  Stats: 35 lines in 4 files changed: 0 ins; 16 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/25559.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25559/head:pull/25559

PR: https://git.openjdk.org/jdk/pull/25559

From alanb at openjdk.org  Thu Jun  5 10:37:53 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Jun 2025 10:37:53 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v9]
In-Reply-To: <Y4CrvczNMFqOaYOJheUhfOD8L-c_iKdtAslcS-ygnIg=.7373ce4f-fd1e-4f9a-b785-e0cf61a32566@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <Y4CrvczNMFqOaYOJheUhfOD8L-c_iKdtAslcS-ygnIg=.7373ce4f-fd1e-4f9a-b785-e0cf61a32566@github.com>
Message-ID: <mIz-ZlnUCQ9vsXsA3MfLr8-GNJYsFi8Ii94b8KbiJbI=.c584134b-ade6-4e55-8649-1471b0d2e161@github.com>

On Thu, 5 Jun 2025 10:10:41 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
>> 
>> Testing: test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move the timestamp to before the try block, change bytes to bytesWritten and remove unnecessary code

src/java.base/share/classes/java/lang/Throwable.java line 124:

> 122:      * exceptions should be traced by JFR.
> 123:      */
> 124:     static boolean jfrTracing;

Are you sure this is okay?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128525269

From egahlin at openjdk.org  Thu Jun  5 10:51:52 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 5 Jun 2025 10:51:52 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v8]
In-Reply-To: <AbC0yTXSfxSe_gfV46sAk4L4sfP-eXuvN2j-tXYrQ18=.86ff17dc-b339-4c4f-98b5-b7c555096ce5@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <C1YJ93tl5cn0qoCtfBvQYbnpKT7gu0yrBDd20V-_LSw=.f9f1e7eb-082c-44c9-85f1-b428dc29dcb3@github.com>
 <AbC0yTXSfxSe_gfV46sAk4L4sfP-eXuvN2j-tXYrQ18=.86ff17dc-b339-4c4f-98b5-b7c555096ce5@github.com>
Message-ID: <-LaEF0pmA3xzw9HcVJlYD91h2ek-nUAfB3BQ1NG--Is=.381146ec-7a22-4fc1-aa2c-032726bc134b@github.com>

On Thu, 5 Jun 2025 09:51:51 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Erik Gahlin has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove the mistakenly added file.
>>  - Fix whitespace
>
> src/jdk.jfr/share/conf/jfr/default.jfc line 845:
> 
>> 843:       <setting name="enabled" control="enable-exceptions">true</setting>
>> 844:       <setting name="stackTrace">true</setting>
>> 845:       <setting name="throttle" control="exceptions-throttle-rate">100/s</setting>
> 
> What was used to propose 100/s as the default and 300/s in profile.jfc?  Just curious if there was a benchmark or test to see the overhead.

It's hard to benchmark since it depends on the application, but we have used 150 events / second for the Object Allocation Sample event without complaints. If you divide one second by 20 ms, the previous threshold, you end up with at most 50 events / second per thread. That said, I think few applications actually have socket read/write around 20-25 ms, so I don't think we should draw too many conclusions from that.

Another way of thinking about it is that the cost of walking maximum 64 stack frames is roughly 5000 ns, so we end up with 100 * 5000 = 500 000 ns or 0.05% of CPU usage. There is also the cost of sampling, and that's why I put in the 1 ms threshold, which puts an upper bound of 1000 sampling attempts per thread.

For profile, I used the same value as Object Allocation Sample.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128549389

From alanb at openjdk.org  Thu Jun  5 11:07:56 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Jun 2025 11:07:56 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v9]
In-Reply-To: <Y4CrvczNMFqOaYOJheUhfOD8L-c_iKdtAslcS-ygnIg=.7373ce4f-fd1e-4f9a-b785-e0cf61a32566@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <Y4CrvczNMFqOaYOJheUhfOD8L-c_iKdtAslcS-ygnIg=.7373ce4f-fd1e-4f9a-b785-e0cf61a32566@github.com>
Message-ID: <iDfQv5IiGJsRClkYco3XrTBrU1XbMUPxSXQ9YlwfA88=.5656cc2f-d519-4eab-951a-5c36babd57c0@github.com>

On Thu, 5 Jun 2025 10:10:41 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
>> 
>> Testing: test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move the timestamp to before the try block, change bytes to bytesWritten and remove unnecessary code

The usages are much cleaner in the update so I think this all good.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25559#pullrequestreview-2899855765

From egahlin at openjdk.org  Thu Jun  5 11:10:54 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 5 Jun 2025 11:10:54 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v9]
In-Reply-To: <mIz-ZlnUCQ9vsXsA3MfLr8-GNJYsFi8Ii94b8KbiJbI=.c584134b-ade6-4e55-8649-1471b0d2e161@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <Y4CrvczNMFqOaYOJheUhfOD8L-c_iKdtAslcS-ygnIg=.7373ce4f-fd1e-4f9a-b785-e0cf61a32566@github.com>
 <mIz-ZlnUCQ9vsXsA3MfLr8-GNJYsFi8Ii94b8KbiJbI=.c584134b-ade6-4e55-8649-1471b0d2e161@github.com>
Message-ID: <dk_r3oQg_7Ir8nrdVEVm3K3iJ8JX5GM6Bx9iC8k7jXc=.35d39c84-62a2-474a-9c3d-8496474dddee@github.com>

On Thu, 5 Jun 2025 10:35:10 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move the timestamp to before the try block, change bytes to bytesWritten and remove unnecessary code
>
> src/java.base/share/classes/java/lang/Throwable.java line 124:
> 
>> 122:      * exceptions should be traced by JFR.
>> 123:      */
>> 124:     static boolean jfrTracing;
> 
> Are you sure this is okay?

When JFR starts the JVM is brought to safepoint so the whole heap becomes visible. We have used it for socket events without any issues.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25559#discussion_r2128580995

From egahlin at openjdk.org  Thu Jun  5 11:20:52 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 5 Jun 2025 11:20:52 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v9]
In-Reply-To: <Y4CrvczNMFqOaYOJheUhfOD8L-c_iKdtAslcS-ygnIg=.7373ce4f-fd1e-4f9a-b785-e0cf61a32566@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <Y4CrvczNMFqOaYOJheUhfOD8L-c_iKdtAslcS-ygnIg=.7373ce4f-fd1e-4f9a-b785-e0cf61a32566@github.com>
Message-ID: <FjjoB-kxB5mI8i2jb_jxw9kkTbwzudcRZnmXQmdWdms=.4446bbc6-7c65-4200-8fd8-9660b7dc30cb@github.com>

On Thu, 5 Jun 2025 10:10:41 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
>> 
>> Testing: test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move the timestamp to before the try block, change bytes to bytesWritten and remove unnecessary code

Thanks for the reviews, the offer methods turned out nicely.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25559#issuecomment-2943787262

From mgronlun at openjdk.org  Thu Jun  5 11:35:53 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 5 Jun 2025 11:35:53 GMT
Subject: RFR: 8351594: JFR: Rate-limited sampling of Java events [v9]
In-Reply-To: <Y4CrvczNMFqOaYOJheUhfOD8L-c_iKdtAslcS-ygnIg=.7373ce4f-fd1e-4f9a-b785-e0cf61a32566@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
 <Y4CrvczNMFqOaYOJheUhfOD8L-c_iKdtAslcS-ygnIg=.7373ce4f-fd1e-4f9a-b785-e0cf61a32566@github.com>
Message-ID: <gn5HwfhUBgCGFVHOTLTYdpOyCN1GJ2_cJtAmKGIsiBI=.7a0fd2dd-0584-4b56-a15b-29dcf16c7b7d@github.com>

On Thu, 5 Jun 2025 10:10:41 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
>> 
>> Testing: test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move the timestamp to before the try block, change bytes to bytesWritten and remove unnecessary code

Marked as reviewed by mgronlun (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25559#pullrequestreview-2899934064

From egahlin at openjdk.org  Thu Jun  5 11:39:01 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 5 Jun 2025 11:39:01 GMT
Subject: Integrated: 8351594: JFR: Rate-limited sampling of Java events
In-Reply-To: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
References: <aIPN0JA2t7ILFYU1r11ueZ9UewNUBo1sFgMYQkEJj1s=.7827ebee-e0ba-4308-b668-d0256a7d40f2@github.com>
Message-ID: <AhEyXqirLtAgGs8Pkoa2uv6V1EyWqdENXIwyjcE_lxY=.957d323b-e3cd-413f-934d-e183bf6b43e5@github.com>

On Fri, 30 May 2025 22:30:25 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of an enhancement that adds rate-limited sampling to Java events, including five events in the JDK (SocketRead, SocketWrite, FileRead, FileWrite, and JavaExceptionThrow).
> 
> Testing: test/jdk/jdk/jfr
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: eb770a06
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/eb770a060ad86d69b38df7d11622e9e25a528e1d
Stats:     1346 lines in 37 files changed: 1056 ins; 174 del; 116 mod

8351594: JFR: Rate-limited sampling of Java events

Reviewed-by: mgronlun, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/25559

From egahlin at openjdk.org  Thu Jun  5 12:59:01 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 5 Jun 2025 12:59:01 GMT
Subject: RFR: 8358689:
 test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java does not build
 after JDK-8351594
Message-ID: <tgpoS5YCa5j2bWMotbbIsna8WH5dCN9wsZ5INlUiel4=.578e3bb7-2b24-4a40-8fe5-15a4a860abea@github.com>

Could I have a review of a benchmark that failed to compile due to updated method signatures for the SocketRead and SocketWrite events?

Testing:  make test TEST="micro:java.net.SocketEventOverhead"

Thanks
Erik

-------------

Commit messages:
 - Initial

Changes: https://git.openjdk.org/jdk/pull/25661/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25661&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358689
  Stats: 12 lines in 1 file changed: 0 ins; 6 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/25661.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25661/head:pull/25661

PR: https://git.openjdk.org/jdk/pull/25661

From alanb at openjdk.org  Thu Jun  5 13:01:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Jun 2025 13:01:52 GMT
Subject: RFR: 8358689:
 test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java does not build
 after JDK-8351594
In-Reply-To: <tgpoS5YCa5j2bWMotbbIsna8WH5dCN9wsZ5INlUiel4=.578e3bb7-2b24-4a40-8fe5-15a4a860abea@github.com>
References: <tgpoS5YCa5j2bWMotbbIsna8WH5dCN9wsZ5INlUiel4=.578e3bb7-2b24-4a40-8fe5-15a4a860abea@github.com>
Message-ID: <n5dJ49i91RaJF6nksJXkkcaxn1ChP8h2GDGW25nFq9E=.5ebb0f5b-6625-4f03-b01a-0c13e2282159@github.com>

On Thu, 5 Jun 2025 12:49:18 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a benchmark that failed to compile due to updated method signatures for the SocketRead and SocketWrite events?
> 
> Testing:  make test TEST="micro:java.net.SocketEventOverhead"
> 
> Thanks
> Erik

I assume you'll bump the copyright header date before integrating.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25661#pullrequestreview-2900233674

From alanb at openjdk.org  Thu Jun  5 13:08:37 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Jun 2025 13:08:37 GMT
Subject: RFR: 8358689:
 test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java does not build
 after JDK-8351594 [v2]
In-Reply-To: <SJbRU5TUwuClu518OxbrWgS6FlAjWyLHDsgv_JQxoI8=.4bca96b2-6cd5-4e9d-9822-396106e518c2@github.com>
References: <tgpoS5YCa5j2bWMotbbIsna8WH5dCN9wsZ5INlUiel4=.578e3bb7-2b24-4a40-8fe5-15a4a860abea@github.com>
 <SJbRU5TUwuClu518OxbrWgS6FlAjWyLHDsgv_JQxoI8=.4bca96b2-6cd5-4e9d-9822-396106e518c2@github.com>
Message-ID: <INWvZPDKCK2brT4tRVULII5aQpz1m410AGhceg0PbYY=.017aad4d-4140-49ad-b716-9ca1b4a9501e@github.com>

On Thu, 5 Jun 2025 13:05:39 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have a review of a benchmark that failed to compile due to updated method signatures for the SocketRead and SocketWrite events?
>> 
>> Testing:  make test TEST="micro:java.net.SocketEventOverhead"
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated copyright header date

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25661#pullrequestreview-2900255555

From egahlin at openjdk.org  Thu Jun  5 13:08:37 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 5 Jun 2025 13:08:37 GMT
Subject: RFR: 8358689:
 test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java does not build
 after JDK-8351594 [v2]
In-Reply-To: <tgpoS5YCa5j2bWMotbbIsna8WH5dCN9wsZ5INlUiel4=.578e3bb7-2b24-4a40-8fe5-15a4a860abea@github.com>
References: <tgpoS5YCa5j2bWMotbbIsna8WH5dCN9wsZ5INlUiel4=.578e3bb7-2b24-4a40-8fe5-15a4a860abea@github.com>
Message-ID: <SJbRU5TUwuClu518OxbrWgS6FlAjWyLHDsgv_JQxoI8=.4bca96b2-6cd5-4e9d-9822-396106e518c2@github.com>

> Could I have a review of a benchmark that failed to compile due to updated method signatures for the SocketRead and SocketWrite events?
> 
> Testing:  make test TEST="micro:java.net.SocketEventOverhead"
> 
> Thanks
> Erik

Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:

  Updated copyright header date

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25661/files
  - new: https://git.openjdk.org/jdk/pull/25661/files/d7fac3dc..9720d063

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25661&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25661&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25661.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25661/head:pull/25661

PR: https://git.openjdk.org/jdk/pull/25661

From egahlin at openjdk.org  Thu Jun  5 13:11:56 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 5 Jun 2025 13:11:56 GMT
Subject: Integrated: 8358689:
 test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java does not build
 after JDK-8351594
In-Reply-To: <tgpoS5YCa5j2bWMotbbIsna8WH5dCN9wsZ5INlUiel4=.578e3bb7-2b24-4a40-8fe5-15a4a860abea@github.com>
References: <tgpoS5YCa5j2bWMotbbIsna8WH5dCN9wsZ5INlUiel4=.578e3bb7-2b24-4a40-8fe5-15a4a860abea@github.com>
Message-ID: <r_MPuRk3gTEN5qXaceNF8A7JQN4JiHciDqLonPRJvBg=.e3153a6a-038d-4d2a-952d-140853ab6d3b@github.com>

On Thu, 5 Jun 2025 12:49:18 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a benchmark that failed to compile due to updated method signatures for the SocketRead and SocketWrite events?
> 
> Testing:  make test TEST="micro:java.net.SocketEventOverhead"
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: 33ed7c18
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/33ed7c1842e61664c1ad0ea4d29f20728c89e06c
Stats:     13 lines in 1 file changed: 0 ins; 6 del; 7 mod

8358689: test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java does not build  after JDK-8351594

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/25661

From vyazici at openjdk.org  Thu Jun  5 13:36:00 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 5 Jun 2025 13:36:00 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher
Message-ID: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>

Simplifies content streaming for `HttpRequest.BodyPublishers::ofFile(Path)`, which delegates to `RequestPublishers.FilePublisher::create(Path)`. This effectively replaces all usages of `FileInputStream::new` in `HttpClient` with `Files::newInputStream(Path)`. See the JBS ticket description for the full story.

Also removing certain test files which were rendered redundant after `SecurityManager` removal. We do this in this PR, since tests were added due to touched lines.

`tier1,2` results on b5f3c8dc6f4 are attached to the ticket.

-------------

Commit messages:
 - Remove redundant tests
 - Remove redundant OIO usage in `RequestPublishers`

Changes: https://git.openjdk.org/jdk/pull/25662/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25662&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358688
  Stats: 744 lines in 3 files changed: 10 ins; 731 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/25662.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25662/head:pull/25662

PR: https://git.openjdk.org/jdk/pull/25662

From michaelm at openjdk.org  Thu Jun  5 13:41:51 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 5 Jun 2025 13:41:51 GMT
Subject: RFR: 8351983: HttpCookie Parser Incorrectly Handles Cookies with
 Expires Attribute
In-Reply-To: <CiYqkEPrqUFI0pTty0rmfqNhiCai5qzBlLWErW7shsQ=.1781f325-bc7a-4e88-bc6f-4f0e57acdca3@github.com>
References: <ciW08mWc__2KkinLshBblHOPcHNur3XRpjm8NmFKhg0=.d6a2998f-b16b-4014-a167-c710a8fba107@github.com>
 <1PtbkKsE2x1KuF8X43mXZXuwfvHb5jKRa2qWultBqBw=.343937c8-728e-4c90-a75e-e970f8a105d1@github.com>
 <CiYqkEPrqUFI0pTty0rmfqNhiCai5qzBlLWErW7shsQ=.1781f325-bc7a-4e88-bc6f-4f0e57acdca3@github.com>
Message-ID: <tzuoZ1uxqjAS6n7iWittbisexIBAy5juTyhKY6-hNlw=.2c40e15e-3543-4e26-9898-bdf4ee75e443@github.com>

On Thu, 5 Jun 2025 05:31:28 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> test/jdk/java/net/HttpCookie/MaxAgeExpires.java line 67:
>> 
>>> 65:         new Test(-1, "Thu, 01 Jan 2024 00:00:00 GMT", 0, true),
>>> 66:         new Test(1000, "Thu, 01 Jan 2024 00:00:00 GMT", 1000, false),
>>> 67:         new Test(0, "Thu, 01 Jan 2024 00:00:00 GMT", 0, true),
>> 
>> Maybe you could add a test case with maxAge=1000 and expires = set at the current time + 500s. The expected maxAge would be 1000.
>> 
>> Something like:
>> 
>> 
>> static final String NOW_PLUS_500 =
>>     DateTimeFormatter.RFC_1123_DATE_TIME.format(
>>         java.time.ZonedDateTime.ofInstant(Instant.now().plusSeconds(500), ZoneId.of("UTC")));
>> 
>> ...
>> 
>> 
>>     new Test(1000, NOW_PLUS_500, 1000, false),
>> 
>> 
>> Ideally we'd like to test the same with maxAge = -1, but that could be tricky since we can't know in advance the exact value that will be computed for the new `maxAge`.
>
> Alternatively, we could create a `HttpCookie::parse` method<sup>1</sup> accepting a `long currentTimeMillis`, and precisely determine the expected value?
> 
> <sup>1</sup> This can either be private and accessed via reflection, or package-private and accessed by placing the test in the same package.

I'll look into doing both of those. So long as we are immune to timing related issues it seems reasonable. By the way, I will push an implementation update first, which results from existing cookie regression failures.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25636#discussion_r2128885121

From michaelm at openjdk.org  Thu Jun  5 13:48:15 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 5 Jun 2025 13:48:15 GMT
Subject: RFR: 8351983: HttpCookie Parser Incorrectly Handles Cookies with
 Expires Attribute [v2]
In-Reply-To: <ciW08mWc__2KkinLshBblHOPcHNur3XRpjm8NmFKhg0=.d6a2998f-b16b-4014-a167-c710a8fba107@github.com>
References: <ciW08mWc__2KkinLshBblHOPcHNur3XRpjm8NmFKhg0=.d6a2998f-b16b-4014-a167-c710a8fba107@github.com>
Message-ID: <TROcHX3i30qFRqW6TMktbK2I21tJ7BwaHRCo970SoxQ=.b883f00f-758c-4f01-a17d-27bd538e8f3b@github.com>

> 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 two additional commits since the last revision:

 - copyright
 - impl update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25636/files
  - new: https://git.openjdk.org/jdk/pull/25636/files/cf25c055..53d5c25e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25636&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25636&range=00-01

  Stats: 11 lines in 1 file changed: 6 ins; 0 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

From michaelm at openjdk.org  Thu Jun  5 13:48:15 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 5 Jun 2025 13:48:15 GMT
Subject: RFR: 8351983: HttpCookie Parser Incorrectly Handles Cookies with
 Expires Attribute [v2]
In-Reply-To: <k9TT7coEMpzPZqYQYYCwY4MB5XxmLnYngD8EpmVqefA=.a29c26ef-0883-4911-91b2-fbb1168ef4f2@github.com>
References: <ciW08mWc__2KkinLshBblHOPcHNur3XRpjm8NmFKhg0=.d6a2998f-b16b-4014-a167-c710a8fba107@github.com>
 <k9TT7coEMpzPZqYQYYCwY4MB5XxmLnYngD8EpmVqefA=.a29c26ef-0883-4911-91b2-fbb1168ef4f2@github.com>
Message-ID: <LKv5Ilu5XVcEkrOmBRHYHsVA77stsf8BNC8cs73jIME=.66b2b095-14f3-4e18-b1f3-6c3b86c11775@github.com>

On Thu, 5 Jun 2025 05:32:56 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Aren't we missing a `@run` tag?

@run defaults to running the main method

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25636#discussion_r2128895452

From jpai at openjdk.org  Thu Jun  5 14:02:49 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 5 Jun 2025 14:02:49 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher
In-Reply-To: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
Message-ID: <AkZxDg4SBszshYpQxhoDey_HnI-JbmVc1zv52ASOYZQ=.7d38cf2d-00bc-41b0-ab06-ccfbfbde1e97@github.com>

On Thu, 5 Jun 2025 13:30:10 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Simplifies content streaming for `HttpRequest.BodyPublishers::ofFile(Path)`, which delegates to `RequestPublishers.FilePublisher::create(Path)`. This effectively replaces all usages of `FileInputStream::new` in `HttpClient` with `Files::newInputStream(Path)`. See the JBS ticket description for the full story.
> 
> Also removing certain test files which were rendered redundant after `SecurityManager` removal. We do this in this PR, since tests were added due to touched lines.
> 
> `tier1,2` results on b5f3c8dc6f4 are attached to the ticket.

src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java line 269:

> 267:                 // The old code was using `FileInputStream::new`, which throws `FNFE` if file doesn't exist.
> 268:                 // Preserving that behaviour after migrating to `Files::newInputStream`:
> 269:                 t = new FileNotFoundException(path + " (No such file or directory)");

Hello Volkan, just some initial comments. I think this `Files.isRegularFile(...)` check and the `Files.newInputStream(...)` call should be done in `RequestPublishers.create(...)` instead of here in subscribe. That way the checks happen when the `BodyPublishers.ofFile(...)` gets invoked instead of at subscription time. That then means that this `FilePublisher` will continue to accept a `InputStream` in its constructor, created out of a successful call to `Files.newInputStream()`. 

Moving these checks and call into `RequestPublishers.create(...)` will also mean that we won't need the code comments explaining why a `FileNotFoundException` gets thrown, because both `BodyPublishers.ofFile(...)` and the (internal) `RequestPublishers.create(...)` are already specified to throw `FileNotFoundException`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25662#discussion_r2128933747

From jpai at openjdk.org  Thu Jun  5 14:05:50 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 5 Jun 2025 14:05:50 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher
In-Reply-To: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
Message-ID: <E81H3NwQw1ijnmTGXSZeCtG1wqamKMBkixYfVfJPtPo=.227e7a73-62fc-40cb-b09d-1b31f62e621a@github.com>

On Thu, 5 Jun 2025 13:30:10 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Also removing certain test files which were rendered redundant after SecurityManager removal. We do this in this PR, since tests were added due to touched lines.

I think, if it's possible, then it might still be better to remove those tests independently in a separate task. That way that issue can be linked to the SecurityManager removal work in https://bugs.openjdk.org/browse/JDK-8338411. But please wait for Daniel's suggestion on whether it needs to be a separate task.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25662#issuecomment-2944565919

From jpai at openjdk.org  Thu Jun  5 14:09:51 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 5 Jun 2025 14:09:51 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher
In-Reply-To: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
Message-ID: <2yNe_fisaiWeFYpJl03YfXn0pD064-TXp192iM23ObE=.96a8ae4d-469a-4090-92c4-aaaca921c75b@github.com>

On Thu, 5 Jun 2025 13:30:10 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Simplifies content streaming for `HttpRequest.BodyPublishers::ofFile(Path)`, which delegates to `RequestPublishers.FilePublisher::create(Path)`. This effectively replaces all usages of `FileInputStream::new` in `HttpClient` with `Files::newInputStream(Path)`. See the JBS ticket description for the full story.
> 
> Also removing certain test files which were rendered redundant after `SecurityManager` removal. We do this in this PR, since tests were added due to touched lines.
> 
> `tier1,2` results on b5f3c8dc6f4 are attached to the ticket.

While at it, I think we should also introduce a regression test which does a `BodyPublishers.ofFile(Path)` against a `Path` provided by a ZIP filesystem or some such filesystem which was the cause for failures reported in https://bugs.openjdk.org/browse/JDK-8235459.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25662#issuecomment-2944592755

From dfuchs at openjdk.org  Thu Jun  5 15:21:51 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 5 Jun 2025 15:21:51 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher
In-Reply-To: <AkZxDg4SBszshYpQxhoDey_HnI-JbmVc1zv52ASOYZQ=.7d38cf2d-00bc-41b0-ab06-ccfbfbde1e97@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
 <AkZxDg4SBszshYpQxhoDey_HnI-JbmVc1zv52ASOYZQ=.7d38cf2d-00bc-41b0-ab06-ccfbfbde1e97@github.com>
Message-ID: <BvQ1EgzoCFcSrZ4mXCJYauXhcqP9YMo30YvCZeUtz-M=.533cab9a-db34-4620-8db5-33d12c44f26b@github.com>

On Thu, 5 Jun 2025 13:59:47 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Simplifies content streaming for `HttpRequest.BodyPublishers::ofFile(Path)`, which delegates to `RequestPublishers.FilePublisher::create(Path)`. This effectively replaces all usages of `FileInputStream::new` in `HttpClient` with `Files::newInputStream(Path)`. See the JBS ticket description for the full story.
>> 
>> Also removing certain test files which were rendered redundant after `SecurityManager` removal. We do this in this PR, since tests were added due to touched lines.
>> 
>> `tier1,2` results on b5f3c8dc6f4 are attached to the ticket.
>
> src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java line 269:
> 
>> 267:                 // The old code was using `FileInputStream::new`, which throws `FNFE` if file doesn't exist.
>> 268:                 // Preserving that behaviour after migrating to `Files::newInputStream`:
>> 269:                 t = new FileNotFoundException(path + " (No such file or directory)");
> 
> Hello Volkan, just some initial comments. I think this `Files.isRegularFile(...)` check and the `Files.newInputStream(...)` call should be done in `RequestPublishers.create(...)` instead of here in subscribe. That way the checks happen when the `BodyPublishers.ofFile(...)` gets invoked instead of at subscription time. That then means that this `FilePublisher` will continue to accept a `InputStream` in its constructor, created out of a successful call to `Files.newInputStream()`. 
> 
> Moving these checks and call into `RequestPublishers.create(...)` will also mean that we won't need the code comments explaining why a `FileNotFoundException` gets thrown, because both `BodyPublishers.ofFile(...)` and the (internal) `RequestPublishers.create(...)` are already specified to throw `FileNotFoundException`

Good idea. FWIW, and ulness I'm mistaken, I believe the old code was not always throwing `FileNotFoundException` - but might have thrown `NoSuchFileException` if  using  a non-default filesystem. If `FileNotFoundException` is specified and `NoSuchFileException` is not then that's probably a good change of behaviour.

Could be worth a release note (if that's the case and the behaviour changed) - but probably not a CSR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25662#discussion_r2129108800

From dfuchs at openjdk.org  Thu Jun  5 15:26:54 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 5 Jun 2025 15:26:54 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher
In-Reply-To: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
Message-ID: <Na5AXkI3TELZroBSi9CnRpgiRVXomFi6pVqIvvXyt_Y=.ade76034-384c-4fb9-9b21-b28f11e94473@github.com>

On Thu, 5 Jun 2025 13:30:10 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Simplifies content streaming for `HttpRequest.BodyPublishers::ofFile(Path)`, which delegates to `RequestPublishers.FilePublisher::create(Path)`. This effectively replaces all usages of `FileInputStream::new` in `HttpClient` with `Files::newInputStream(Path)`. See the JBS ticket description for the full story.
> 
> Also removing certain test files which were rendered redundant after `SecurityManager` removal. We do this in this PR, since tests were added due to touched lines.
> 
> `tier1,2` results on b5f3c8dc6f4 are attached to the ticket.

Yes on both counts. Note that the removed tests where also using ZipFileSystem. It would be better to remove them with another PR, after this change is integrated, and only if we can say with certainty that whatever they test is already covered by other tests.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25662#issuecomment-2944977728

From mullan at openjdk.org  Thu Jun  5 17:47:54 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 5 Jun 2025 17:47:54 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are
 not being checked with default SunX509 key manager [v4]
In-Reply-To: <xvvfE1iwaZVaj8meVlXZ2iiaEeioyklVWIwUxkMmk8A=.5f16c35d-1e1e-4146-b04e-5abfc4493ed2@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <xvvfE1iwaZVaj8meVlXZ2iiaEeioyklVWIwUxkMmk8A=.5f16c35d-1e1e-4146-b04e-5abfc4493ed2@github.com>
Message-ID: <s3KKr3corBQNC4HO3LqGCPCvoEMf45X3Q3ch3aUCAE0=.86e1d246-19c1-4222-971f-50f2a96cda1f@github.com>

On Wed, 14 May 2025 18:16:13 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> 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.
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make the test run on TLSv1.3

Some initial comments.

src/java.base/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java line 264:

> 262:      * the peer (if any).
> 263:      *
> 264:      * @since 1.5

I would remove the `@since 1.5` from these methods. It isn't relevant anymore since this is an internal class and that version is no longer supported. That version info is in the `X509ExtendedKeyManager` API which is sufficient.

src/java.base/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java line 395:

> 393:                 if (SSLLogger.isOn && SSLLogger.isOn("keymanager")) {
> 394:                     SSLLogger.fine("Ignore alias " + alias +
> 395:                             ": certificate list does not conform to " +

suggest saying "certificate chain" not "certificate list".

test/lib/jdk/test/lib/security/CertificateBuilder.java line 244:

> 242:      * @throws IOException if an encoding error occurs.
> 243:      */
> 244:     public CertificateBuilder addSubjectAltNameIPExt(List<String> IPAddresses)

variables usually start with lower case letter, so suggest `ipAddresses`

-------------

PR Review: https://git.openjdk.org/jdk/pull/25016#pullrequestreview-2900744862
PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2129536065
PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2129556680
PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2129090967

From mullan at openjdk.org  Thu Jun  5 19:34:53 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 5 Jun 2025 19:34:53 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are
 not being checked with default SunX509 key manager [v4]
In-Reply-To: <xvvfE1iwaZVaj8meVlXZ2iiaEeioyklVWIwUxkMmk8A=.5f16c35d-1e1e-4146-b04e-5abfc4493ed2@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <xvvfE1iwaZVaj8meVlXZ2iiaEeioyklVWIwUxkMmk8A=.5f16c35d-1e1e-4146-b04e-5abfc4493ed2@github.com>
Message-ID: <zVgwYqUGhLYWXk3JSCXc7rrm_wNtq_EW4FFRQp1BEYA=.b4d50963-ec2b-4191-a7f2-0ccf60fc2564@github.com>

On Wed, 14 May 2025 18:16:13 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> 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.
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make the test run on TLSv1.3

test/jdk/sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java line 1:

> 1: /*

Are these changes relevant to this issue? It doesn't use a SunX509 TrustManager AFAICT.

test/jdk/sun/security/ssl/X509KeyManager/PeerConstraintsCheck.java line 1:

> 1: /*

I am trying to figure out when the algorithm constraints are enabled, why the key isn't being selected. I don't see anywhere that you are setting the algorithm constraints property.

Please add some more comments explaining how the exception case occurs.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2129881920
PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2130018039

From vyazici at openjdk.org  Fri Jun  6 07:41:00 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 6 Jun 2025 07:41:00 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher
In-Reply-To: <BvQ1EgzoCFcSrZ4mXCJYauXhcqP9YMo30YvCZeUtz-M=.533cab9a-db34-4620-8db5-33d12c44f26b@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
 <AkZxDg4SBszshYpQxhoDey_HnI-JbmVc1zv52ASOYZQ=.7d38cf2d-00bc-41b0-ab06-ccfbfbde1e97@github.com>
 <BvQ1EgzoCFcSrZ4mXCJYauXhcqP9YMo30YvCZeUtz-M=.533cab9a-db34-4620-8db5-33d12c44f26b@github.com>
Message-ID: <De2LNDIDoG389ntYweSbxLkWUPINqFUEmbKz45tePGI=.8621bda9-c0fc-4a5d-8c10-9c20c307a86a@github.com>

On Thu, 5 Jun 2025 15:19:09 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java line 269:
>> 
>>> 267:                 // The old code was using `FileInputStream::new`, which throws `FNFE` if file doesn't exist.
>>> 268:                 // Preserving that behaviour after migrating to `Files::newInputStream`:
>>> 269:                 t = new FileNotFoundException(path + " (No such file or directory)");
>> 
>> Hello Volkan, just some initial comments. I think this `Files.isRegularFile(...)` check and the `Files.newInputStream(...)` call should be done in `RequestPublishers.create(...)` instead of here in subscribe. That way the checks happen when the `BodyPublishers.ofFile(...)` gets invoked instead of at subscription time. That then means that this `FilePublisher` will continue to accept a `InputStream` in its constructor, created out of a successful call to `Files.newInputStream()`. 
>> 
>> Moving these checks and call into `RequestPublishers.create(...)` will also mean that we won't need the code comments explaining why a `FileNotFoundException` gets thrown, because both `BodyPublishers.ofFile(...)` and the (internal) `RequestPublishers.create(...)` are already specified to throw `FileNotFoundException`
>
> Good idea. FWIW, and ulness I'm mistaken, I believe the old code was not always throwing `FileNotFoundException` - but might have thrown `NoSuchFileException` if  using  a non-default filesystem. If `FileNotFoundException` is specified and `NoSuchFileException` is not then that's probably a good change of behaviour.
> 
> Could be worth a release note (if that's the case and the behaviour changed) - but probably not a CSR.

Placing `isRegularFile()` check to `create()` indeed was my initial attempt too. Though that resulted in a behavior change: Earlier the regular file check was performed by `FIS::new` at subscription, hence, `NSFE` (yes, `FIS::new` throws `NSFE` when passed a not-regular file, e.g., a directory) was thrown at `subscribe()`. Moving this check from `subscribe()` to `create()` breaks the `RelayingPublishers` test, since failure gets moved from subscription-time to [reactive pipeline] assembly-time.

Would you prefer me to

1. keep things as is,
2. move `isRegularFile()` to `create()`, or
3. move `isRegularFile()` to `create()` and file a CSR?

Note that I don't think we can avoid the `NSFE`-to-`FNFE` translation in `subscribe()`, since, whatever earlier check we do before `Files::newIS`, file might get changed afterwards, and `NSFE` can still be thrown at the `Files::newIS` invocation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25662#discussion_r2131681143

From vyazici at openjdk.org  Fri Jun  6 07:46:56 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 6 Jun 2025 07:46:56 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher
In-Reply-To: <De2LNDIDoG389ntYweSbxLkWUPINqFUEmbKz45tePGI=.8621bda9-c0fc-4a5d-8c10-9c20c307a86a@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
 <AkZxDg4SBszshYpQxhoDey_HnI-JbmVc1zv52ASOYZQ=.7d38cf2d-00bc-41b0-ab06-ccfbfbde1e97@github.com>
 <BvQ1EgzoCFcSrZ4mXCJYauXhcqP9YMo30YvCZeUtz-M=.533cab9a-db34-4620-8db5-33d12c44f26b@github.com>
 <De2LNDIDoG389ntYweSbxLkWUPINqFUEmbKz45tePGI=.8621bda9-c0fc-4a5d-8c10-9c20c307a86a@github.com>
Message-ID: <6bxAZ3QVwBhyDLLkTYyvoh9woau5FZBOjc89zHe05ts=.ab7c87a1-743c-4cc8-ab9b-5c261c0f8727@github.com>

On Fri, 6 Jun 2025 07:38:21 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Good idea. FWIW, and ulness I'm mistaken, I believe the old code was not always throwing `FileNotFoundException` - but might have thrown `NoSuchFileException` if  using  a non-default filesystem. If `FileNotFoundException` is specified and `NoSuchFileException` is not then that's probably a good change of behaviour.
>> 
>> Could be worth a release note (if that's the case and the behaviour changed) - but probably not a CSR.
>
> Placing `isRegularFile()` check to `create()` indeed was my initial attempt too. Though that resulted in a behavior change: Earlier the regular file check was performed by `FIS::new` at subscription, hence, `NSFE` (yes, `FIS::new` throws `NSFE` when passed a not-regular file, e.g., a directory) was thrown at `subscribe()`. Moving this check from `subscribe()` to `create()` breaks the `RelayingPublishers` test, since failure gets moved from subscription-time to [reactive pipeline] assembly-time.
> 
> Would you prefer me to
> 
> 1. keep things as is,
> 2. move `isRegularFile()` to `create()`, or
> 3. move `isRegularFile()` to `create()` and file a CSR?
> 
> Note that I don't think we can avoid the `NSFE`-to-`FNFE` translation in `subscribe()`, since, whatever earlier check we do before `Files::newIS`, file might get changed afterwards, and `NSFE` can still be thrown at the `Files::newIS` invocation.

> I believe the old code was not always throwing `FileNotFoundException` - but might have thrown `NoSuchFileException` if using a non-default filesystem.

@dfuch, correct. If `Path` is associated with a file system that doesn't support `Path::toFile`<sup>1</sup>, earlier users would get `Files::newIS` exceptions (which were indeed undocumented), whereas others would get `FIS::new` exceptions.

<sup>1</sup> Allow me to note that I intentionally avoid using "default file system" term, since, IMHO, that distracts us from the problem: file systems that don't support `Path::toFile`. The "default file system" is required to support that feature, but there can be other file systems that support that too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25662#discussion_r2131690023

From vyazici at openjdk.org  Fri Jun  6 07:49:52 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 6 Jun 2025 07:49:52 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher
In-Reply-To: <E81H3NwQw1ijnmTGXSZeCtG1wqamKMBkixYfVfJPtPo=.227e7a73-62fc-40cb-b09d-1b31f62e621a@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
 <E81H3NwQw1ijnmTGXSZeCtG1wqamKMBkixYfVfJPtPo=.227e7a73-62fc-40cb-b09d-1b31f62e621a@github.com>
Message-ID: <Etcw0mg_sgramkurmIIbMUrNa0sOab7UUjFTebx-x4g=.b132b48c-c265-469d-9b2d-98197cad628a@github.com>

On Thu, 5 Jun 2025 14:03:30 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> it might still be better to remove those tests independently in a separate task.

@jaikiran, sure, will do.

> While at it, I think we should also introduce a regression test which does a `BodyPublishers.ofFile(Path)` against a `Path` provided by a ZIP filesystem or some such filesystem which was the cause for failures reported in https://bugs.openjdk.org/browse/JDK-8235459.

Such a test already exists: `FilePublisherTest`. I deleted its SM counterpart: `FilePublisherPermsTest`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25662#issuecomment-2948394630

From vyazici at openjdk.org  Fri Jun  6 08:11:35 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 6 Jun 2025 08:11:35 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher [v2]
In-Reply-To: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
Message-ID: <NrmUYpAN1zYyIOPglMngLW5c2rTwvG3dmnUxL6LaeX0=.f8c101ee-1fce-416a-9b45-379643f933a4@github.com>

> Simplifies content streaming for `HttpRequest.BodyPublishers::ofFile(Path)`, which delegates to `RequestPublishers.FilePublisher::create(Path)`. This effectively replaces all usages of `FileInputStream::new` in `HttpClient` with `Files::newInputStream(Path)`. See the JBS ticket description for the full story.
> 
> Also removing certain test files which were rendered redundant after `SecurityManager` removal. We do this in this PR, since tests were added due to touched lines.
> 
> `tier1,2` results on b5f3c8dc6f4 are attached to the ticket.

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Add back removed SM tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25662/files
  - new: https://git.openjdk.org/jdk/pull/25662/files/b5f3c8dc..0a7800ab

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25662&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25662&range=00-01

  Stats: 701 lines in 2 files changed: 701 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25662.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25662/head:pull/25662

PR: https://git.openjdk.org/jdk/pull/25662

From dfuchs at openjdk.org  Fri Jun  6 08:11:36 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 6 Jun 2025 08:11:36 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher
In-Reply-To: <Etcw0mg_sgramkurmIIbMUrNa0sOab7UUjFTebx-x4g=.b132b48c-c265-469d-9b2d-98197cad628a@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
 <E81H3NwQw1ijnmTGXSZeCtG1wqamKMBkixYfVfJPtPo=.227e7a73-62fc-40cb-b09d-1b31f62e621a@github.com>
 <Etcw0mg_sgramkurmIIbMUrNa0sOab7UUjFTebx-x4g=.b132b48c-c265-469d-9b2d-98197cad628a@github.com>
Message-ID: <6bVFj_49jC11m63oxVFaKgIv0vMr6FsW7PmNrkerp1E=.5b4e8ee8-a5d3-4cc8-a200-91d5cf3a08bf@github.com>

On Fri, 6 Jun 2025 07:47:17 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Such a test already exists: FilePublisherTest. I deleted its SM counterpart: FilePublisherPermsTest.

This test seems to test more things and less things than FilePublisherTest (typically it does test FileNotFoundException). We shouldn't simply delete it, but potentially migrate the parts that are not covered by FilePublisherTest into FilePublisherTest first. Best done in another PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25662#issuecomment-2948435629

From dfuchs at openjdk.org  Fri Jun  6 08:23:55 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 6 Jun 2025 08:23:55 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher [v2]
In-Reply-To: <6bxAZ3QVwBhyDLLkTYyvoh9woau5FZBOjc89zHe05ts=.ab7c87a1-743c-4cc8-ab9b-5c261c0f8727@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
 <AkZxDg4SBszshYpQxhoDey_HnI-JbmVc1zv52ASOYZQ=.7d38cf2d-00bc-41b0-ab06-ccfbfbde1e97@github.com>
 <BvQ1EgzoCFcSrZ4mXCJYauXhcqP9YMo30YvCZeUtz-M=.533cab9a-db34-4620-8db5-33d12c44f26b@github.com>
 <De2LNDIDoG389ntYweSbxLkWUPINqFUEmbKz45tePGI=.8621bda9-c0fc-4a5d-8c10-9c20c307a86a@github.com>
 <6bxAZ3QVwBhyDLLkTYyvoh9woau5FZBOjc89zHe05ts=.ab7c87a1-743c-4cc8-ab9b-5c261c0f8727@github.com>
Message-ID: <0OKk3gOIx3NELEKgqK7lt-YmrK5SSIFrziaswzk3spo=.2e74c90d-2a43-4a24-866d-6aea84e5d357@github.com>

On Fri, 6 Jun 2025 07:44:33 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Placing `isRegularFile()` check to `create()` indeed was my initial attempt too. Though that resulted in a behavior change: Earlier the regular file check was performed by `FIS::new` at subscription, hence, `NSFE` (yes, `FIS::new` throws `NSFE` when passed a not-regular file, e.g., a directory) was thrown at `subscribe()`. Moving this check from `subscribe()` to `create()` breaks the `RelayingPublishers` test, since failure gets moved from subscription-time to [reactive pipeline] assembly-time.
>> 
>> Would you prefer me to
>> 
>> 1. keep things as is,
>> 2. move `isRegularFile()` to `create()`, or
>> 3. move `isRegularFile()` to `create()` and file a CSR?
>> 
>> Note that I don't think we can avoid the `NSFE`-to-`FNFE` translation in `subscribe()`, since, whatever earlier check we do before `Files::newIS`, file might get changed afterwards, and `NSFE` can still be thrown at the `Files::newIS` invocation.
>
>> I believe the old code was not always throwing `FileNotFoundException` - but might have thrown `NoSuchFileException` if using a non-default filesystem.
> 
> @dfuch, correct. If `Path` is associated with a file system that doesn't support `Path::toFile`<sup>1</sup>, earlier users would get `Files::newIS` exceptions (which were indeed undocumented), whereas others would get `FIS::new` exceptions.
> 
> <sup>1</sup> Allow me to note that I intentionally avoid using "default file system" term, since, IMHO, that distracts us from the problem: file systems that don't support `Path::toFile`. The "default file system" is required to support that feature, but there can be other file systems that support that too.

OK

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25662#discussion_r2131745751

From dfuchs at openjdk.org  Fri Jun  6 08:30:50 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 6 Jun 2025 08:30:50 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher [v2]
In-Reply-To: <NrmUYpAN1zYyIOPglMngLW5c2rTwvG3dmnUxL6LaeX0=.f8c101ee-1fce-416a-9b45-379643f933a4@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
 <NrmUYpAN1zYyIOPglMngLW5c2rTwvG3dmnUxL6LaeX0=.f8c101ee-1fce-416a-9b45-379643f933a4@github.com>
Message-ID: <vXFUng_SjGixQMppKv2JRzSklBPMW41moShQgkF4jPM=.9e60b0c0-d8cd-4083-8420-c635b47ede80@github.com>

On Fri, 6 Jun 2025 08:11:35 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Simplifies content streaming for `HttpRequest.BodyPublishers::ofFile(Path)`, which delegates to `RequestPublishers.FilePublisher::create(Path)`. This effectively replaces all usages of `FileInputStream::new` in `HttpClient` with `Files::newInputStream(Path)`. See the JBS ticket description for the full story.
>> 
>> Also removing certain test files which were rendered redundant after `SecurityManager` removal. We do this in this PR, since tests were added due to touched lines.
>> 
>> `tier1,2` results on b5f3c8dc6f4 are attached to the ticket.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add back removed SM tests

The new version LGTM. I wonder if we should add `@bug 8358688` to the various FilePublisher test - or just consider the fix as noreg-cleanup. On the one hand those tests might have failed if you hadn't catched and transformed NSFE. On the other hand they should pass whether this fix is present or not...

src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java line 269:

> 267:                 // The old code was using `FileInputStream::new`, which throws `FNFE` if file doesn't exist.
> 268:                 // Preserving that behaviour after migrating to `Files::newInputStream`:
> 269:                 t = new FileNotFoundException(path + " (No such file or directory)");

I wonder if we should keep `nsfe` as the cause. Does it contain anything interesting in the stack trace that could help debugging if it gets unexpectedly thrown?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25662#issuecomment-2948485426
PR Review Comment: https://git.openjdk.org/jdk/pull/25662#discussion_r2131758853

From vyazici at openjdk.org  Fri Jun  6 11:07:34 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 6 Jun 2025 11:07:34 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher [v3]
In-Reply-To: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
Message-ID: <ol-Q3UNyt_kZAz35ukMK6ppSwc7jrKvFlQ7Bt3BZNk0=.d55c2df6-aa94-4b9e-b0b4-1f76ec73af5d@github.com>

> Simplifies content streaming for `HttpRequest.BodyPublishers::ofFile(Path)`, which delegates to `RequestPublishers.FilePublisher::create(Path)`. This effectively replaces all usages of `FileInputStream::new` in `HttpClient` with `Files::newInputStream(Path)`. See the JBS ticket description for the full story.
> 
> Also removing certain test files which were rendered redundant after `SecurityManager` removal. We do this in this PR, since tests were added due to touched lines.
> 
> `tier1,2` results on b5f3c8dc6f4 are attached to the ticket.

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Update tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25662/files
  - new: https://git.openjdk.org/jdk/pull/25662/files/0a7800ab..9fce1c3b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25662&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25662&range=01-02

  Stats: 29 lines in 2 files changed: 23 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/25662.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25662/head:pull/25662

PR: https://git.openjdk.org/jdk/pull/25662

From vyazici at openjdk.org  Fri Jun  6 11:07:34 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 6 Jun 2025 11:07:34 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher [v2]
In-Reply-To: <vXFUng_SjGixQMppKv2JRzSklBPMW41moShQgkF4jPM=.9e60b0c0-d8cd-4083-8420-c635b47ede80@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
 <NrmUYpAN1zYyIOPglMngLW5c2rTwvG3dmnUxL6LaeX0=.f8c101ee-1fce-416a-9b45-379643f933a4@github.com>
 <vXFUng_SjGixQMppKv2JRzSklBPMW41moShQgkF4jPM=.9e60b0c0-d8cd-4083-8420-c635b47ede80@github.com>
Message-ID: <Kg5B8VmeMikyLo8su3hCkKp3-HX4UY8BfNY6Oh-8IYU=.6bb19b5a-3d26-4292-b0f3-a0ada1e57b30@github.com>

On Fri, 6 Jun 2025 08:25:44 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> I wonder if we should add `@bug 8358688` to the various FilePublisher test - or just consider the fix as noreg-cleanup. On the one hand those tests might have failed if you hadn't catched and transformed NSFE. On the other hand they should pass whether this fix is present or not...

In 9fce1c3b763, I've

- Added `@bug 8358688` to both `RelayingPublishers` and `FilePublisherTest`
- Copied missing `testFileNotFound()` from `FilePublisherPermsTest` to `FilePublisherTest`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25662#issuecomment-2948901297

From vyazici at openjdk.org  Fri Jun  6 11:09:51 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 6 Jun 2025 11:09:51 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher [v2]
In-Reply-To: <vXFUng_SjGixQMppKv2JRzSklBPMW41moShQgkF4jPM=.9e60b0c0-d8cd-4083-8420-c635b47ede80@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
 <NrmUYpAN1zYyIOPglMngLW5c2rTwvG3dmnUxL6LaeX0=.f8c101ee-1fce-416a-9b45-379643f933a4@github.com>
 <vXFUng_SjGixQMppKv2JRzSklBPMW41moShQgkF4jPM=.9e60b0c0-d8cd-4083-8420-c635b47ede80@github.com>
Message-ID: <_EMK2LGYPHG7H97xiE92w2nVTO18Xf0TQMv3-wreRE8=.88849d54-f02f-4e8a-842f-db9da6c91606@github.com>

On Fri, 6 Jun 2025 08:28:30 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add back removed SM tests
>
> src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java line 269:
> 
>> 267:                 // The old code was using `FileInputStream::new`, which throws `FNFE` if file doesn't exist.
>> 268:                 // Preserving that behaviour after migrating to `Files::newInputStream`:
>> 269:                 t = new FileNotFoundException(path + " (No such file or directory)");
> 
> I wonder if we should keep `nsfe` as the cause. Does it contain anything interesting in the stack trace that could help debugging if it gets unexpectedly thrown?

I also wanted to keep the `nsfe` as the cause, though `FNFE::new` doesn't have a public ctor accepting a `Throwable`.

> Does it contain anything interesting in the stack trace that could help debugging if it gets unexpectedly thrown?

Not really:


jshell> java.nio.file.Files.newInputStream(java.nio.file.Path.of("/foo"))
|  Exception java.nio.file.NoSuchFileException: /foo
|        at UnixException.translateToIOException (UnixException.java:92)
|        at UnixException.rethrowAsIOException (UnixException.java:106)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25662#discussion_r2131998716

From dfuchs at openjdk.org  Fri Jun  6 11:15:54 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 6 Jun 2025 11:15:54 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher [v3]
In-Reply-To: <ol-Q3UNyt_kZAz35ukMK6ppSwc7jrKvFlQ7Bt3BZNk0=.d55c2df6-aa94-4b9e-b0b4-1f76ec73af5d@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
 <ol-Q3UNyt_kZAz35ukMK6ppSwc7jrKvFlQ7Bt3BZNk0=.d55c2df6-aa94-4b9e-b0b4-1f76ec73af5d@github.com>
Message-ID: <wk8UD9XvDgqanuaFhXuwpC_Xh1DRnQAV2MDXCKIauHc=.d862f1a9-80bb-4aec-9e5b-35c6af19395c@github.com>

On Fri, 6 Jun 2025 11:07:34 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Simplifies content streaming for `HttpRequest.BodyPublishers::ofFile(Path)`, which delegates to `RequestPublishers.FilePublisher::create(Path)`. This effectively replaces all usages of `FileInputStream::new` in `HttpClient` with `Files::newInputStream(Path)`. See the JBS ticket description for the full story.
>> 
>> Also removing certain test files which were rendered redundant after `SecurityManager` removal. We do this in this PR, since tests were added due to touched lines.
>> 
>> `tier1,2` results on b5f3c8dc6f4 are attached to the ticket.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update tests

LGTM. Maybe wait for comments from @jaikiran before integrating

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25662#pullrequestreview-2904613238

From dfuchs at openjdk.org  Fri Jun  6 11:15:57 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 6 Jun 2025 11:15:57 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher [v2]
In-Reply-To: <_EMK2LGYPHG7H97xiE92w2nVTO18Xf0TQMv3-wreRE8=.88849d54-f02f-4e8a-842f-db9da6c91606@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
 <NrmUYpAN1zYyIOPglMngLW5c2rTwvG3dmnUxL6LaeX0=.f8c101ee-1fce-416a-9b45-379643f933a4@github.com>
 <vXFUng_SjGixQMppKv2JRzSklBPMW41moShQgkF4jPM=.9e60b0c0-d8cd-4083-8420-c635b47ede80@github.com>
 <_EMK2LGYPHG7H97xiE92w2nVTO18Xf0TQMv3-wreRE8=.88849d54-f02f-4e8a-842f-db9da6c91606@github.com>
Message-ID: <NdCTzAMJy09mLdEqbFzzbk1CgGHk4znzb9LxHvKAMaQ=.736d0591-116e-4865-8ef6-71ae5cfeec51@github.com>

On Fri, 6 Jun 2025 11:07:00 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java line 269:
>> 
>>> 267:                 // The old code was using `FileInputStream::new`, which throws `FNFE` if file doesn't exist.
>>> 268:                 // Preserving that behaviour after migrating to `Files::newInputStream`:
>>> 269:                 t = new FileNotFoundException(path + " (No such file or directory)");
>> 
>> I wonder if we should keep `nsfe` as the cause. Does it contain anything interesting in the stack trace that could help debugging if it gets unexpectedly thrown?
>
> I also wanted to keep the `nsfe` as the cause, though `FNFE::new` doesn't have a public ctor accepting a `Throwable`.
> 
>> Does it contain anything interesting in the stack trace that could help debugging if it gets unexpectedly thrown?
> 
> Not really:
> 
> 
> jshell> java.nio.file.Files.newInputStream(java.nio.file.Path.of("/foo"))
> |  Exception java.nio.file.NoSuchFileException: /foo
> |        at UnixException.translateToIOException (UnixException.java:92)
> |        at UnixException.rethrowAsIOException (UnixException.java:106)

Ok - doesn't look too useful.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25662#discussion_r2132003924

From vyazici at openjdk.org  Fri Jun  6 11:15:58 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 6 Jun 2025 11:15:58 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher [v3]
In-Reply-To: <0OKk3gOIx3NELEKgqK7lt-YmrK5SSIFrziaswzk3spo=.2e74c90d-2a43-4a24-866d-6aea84e5d357@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
 <AkZxDg4SBszshYpQxhoDey_HnI-JbmVc1zv52ASOYZQ=.7d38cf2d-00bc-41b0-ab06-ccfbfbde1e97@github.com>
 <BvQ1EgzoCFcSrZ4mXCJYauXhcqP9YMo30YvCZeUtz-M=.533cab9a-db34-4620-8db5-33d12c44f26b@github.com>
 <De2LNDIDoG389ntYweSbxLkWUPINqFUEmbKz45tePGI=.8621bda9-c0fc-4a5d-8c10-9c20c307a86a@github.com>
 <6bxAZ3QVwBhyDLLkTYyvoh9woau5FZBOjc89zHe05ts=.ab7c87a1-743c-4cc8-ab9b-5c261c0f8727@github.com>
 <0OKk3gOIx3NELEKgqK7lt-YmrK5SSIFrziaswzk3spo=.2e74c90d-2a43-4a24-866d-6aea84e5d357@github.com>
Message-ID: <7dNOVjtiCQEgzZkmUU0x8G9mnGcgdwVYLiqBKVccWeU=.d7d978b4-2a2f-493f-88a2-efc20438f83a@github.com>

On Fri, 6 Jun 2025 08:21:31 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>>> I believe the old code was not always throwing `FileNotFoundException` - but might have thrown `NoSuchFileException` if using a non-default filesystem.
>> 
>> @dfuch, correct. If `Path` is associated with a file system that doesn't support `Path::toFile`<sup>1</sup>, earlier users would get `Files::newIS` exceptions (which were indeed undocumented), whereas others would get `FIS::new` exceptions.
>> 
>> <sup>1</sup> Allow me to note that I intentionally avoid using "default file system" term, since, IMHO, that distracts us from the problem: file systems that don't support `Path::toFile`. The "default file system" is required to support that feature, but there can be other file systems that support that too.
>
> OK

> The "default file system" is required to support that feature, but there can be other file systems that support that too.

I need to amend this statement: Per [`Path::toFile` specification]( https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/nio/file/Path.html#toFile()), except the default one obtained by `FileSystems::getDefault`, `FileSystem` implementations are expected to throw `UnsupportedOperationException` on `Path::toFile`. Note that this is enforced by the specification; there is technically nothing blocking a custom `FileSystem` implementation from returning a `File` (i.e., not throwing `UOE`) from `Path::toFile`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25662#discussion_r2132007324

From dfuchs at openjdk.org  Fri Jun  6 11:51:49 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 6 Jun 2025 11:51:49 GMT
Subject: RFR: 8358688: HttpClient: Simplify file streaming in
 RequestPublishers.FilePublisher [v3]
In-Reply-To: <7dNOVjtiCQEgzZkmUU0x8G9mnGcgdwVYLiqBKVccWeU=.d7d978b4-2a2f-493f-88a2-efc20438f83a@github.com>
References: <I6v3XQ0rtObCyoYrW9wzLlcqLwL_X-CDFtVQtxU9Kxg=.239372d9-642e-46bf-a70e-53f3542910d5@github.com>
 <AkZxDg4SBszshYpQxhoDey_HnI-JbmVc1zv52ASOYZQ=.7d38cf2d-00bc-41b0-ab06-ccfbfbde1e97@github.com>
 <BvQ1EgzoCFcSrZ4mXCJYauXhcqP9YMo30YvCZeUtz-M=.533cab9a-db34-4620-8db5-33d12c44f26b@github.com>
 <De2LNDIDoG389ntYweSbxLkWUPINqFUEmbKz45tePGI=.8621bda9-c0fc-4a5d-8c10-9c20c307a86a@github.com>
 <6bxAZ3QVwBhyDLLkTYyvoh9woau5FZBOjc89zHe05ts=.ab7c87a1-743c-4cc8-ab9b-5c261c0f8727@github.com>
 <0OKk3gOIx3NELEKgqK7lt-YmrK5SSIFrziaswzk3spo=.2e74c90d-2a43-4a24-866d-6aea84e5d357@github.com>
 <7dNOVjtiCQEgzZkmUU0x8G9mnGcgdwVYLiqBKVccWeU=.d7d978b4-2a2f-493f-88a2-efc20438f83a@github.com>
Message-ID: <qPDBtQfr4R0zffTC5tVfG40jB7oxwTvtEK0MMYPP33E=.8b344ae4-dbeb-4bde-91a1-b434efa994b3@github.com>

On Fri, 6 Jun 2025 11:13:38 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> OK
>
>> The "default file system" is required to support that feature, but there can be other file systems that support that too.
> 
> I need to amend this statement: Per [`Path::toFile` specification]( https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/nio/file/Path.html#toFile()), except the default one obtained by `FileSystems::getDefault`, `FileSystem` implementations are expected to throw `UnsupportedOperationException` on `Path::toFile`. Note that this is enforced by the specification; there is technically nothing blocking a custom `FileSystem` implementation from returning a `File` (i.e., not throwing `UOE`) from `Path::toFile`.

Thanks for the clarification.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25662#discussion_r2132050544

From dfuchs at openjdk.org  Fri Jun  6 12:00:37 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 6 Jun 2025 12:00:37 GMT
Subject: RFR: 8349910: Implement JEP 517: HTTP/3 for the HTTP Client API
 [v7]
In-Reply-To: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
References: <gjhNQ37EDrc8OAcD01iVJxDmJp6WmwAE9K2zuyUPV4I=.45fd46d7-a6bd-49ab-b233-a57073a4f9b9@github.com>
Message-ID: <UlJlkRDZKsf4zbU26KDVYMCGuksGF6iKh-lFYhQAjIE=.595e3d84-0746-4f01-b02a-087b13b6fcb2@github.com>

> Hi,
> 
> Please find here a PR for the implementation of [JEP 517: HTTP/3 for the HTTP Client API](https://openjdk.org/jeps/517).
> 
> The CSR can be viewed at [JDK-8350588: Implement JEP 517: HTTP/3 for the HTTP Client API](https://bugs.openjdk.org/browse/JDK-8350588)
> 
> This JEP proposes to enhance the HttpClient implementation to support HTTP/3.
> It adds a non-exposed / non-exported internal implementation of the QUIC protocol based on DatagramChannel and the SunJSSE SSLContext provider.

Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 499 commits:

 - merge latest changes from master branch
 - http3: improve H3ConnectionPoolTest.java
 - Fix snippet
 - Improve key destruction
 - merge latest changes from master branch
 - http3: fix bug introduced by Http3ConnectionPool and improved debug logs
 - http3: refactor HTTP/3 connection pool management in a separate class
 - Ignore DestroyFailedExceptions
 - Remove outdated TODO
 - Remove outdated TODO
 - ... and 489 more: https://git.openjdk.org/jdk/compare/65fda5c0...a5a0c7f8

-------------

Changes: https://git.openjdk.org/jdk/pull/24751/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24751&range=06
  Stats: 103750 lines in 473 files changed: 100888 ins; 1345 del; 1517 mod
  Patch: https://git.openjdk.org/jdk/pull/24751.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24751/head:pull/24751

PR: https://git.openjdk.org/jdk/pull/24751

From duke at openjdk.org  Fri Jun  6 14:39:16 2025
From: duke at openjdk.org (p-nima)
Date: Fri, 6 Jun 2025 14:39:16 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit
 of 3 retries [v2]
In-Reply-To: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
Message-ID: <iAIKam-Y0DptYiFNv8b89gA5VOVXc45Jm1Hc4OjH8fs=.43c78b9f-0337-42c0-a623-bffe50fa0cef@github.com>

> 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:

  apply review feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25490/files
  - new: https://git.openjdk.org/jdk/pull/25490/files/cdf78127..2d032564

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25490&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25490&range=00-01

  Stats: 252 lines in 2 files changed: 136 ins; 116 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25490.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25490/head:pull/25490

PR: https://git.openjdk.org/jdk/pull/25490

From duke at openjdk.org  Fri Jun  6 14:50:52 2025
From: duke at openjdk.org (p-nima)
Date: Fri, 6 Jun 2025 14:50:52 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit
 of 3 retries [v2]
In-Reply-To: <4-0FPfF_TcDB7t9yJLz94MM7cPc77dtrMI9-p03O5pc=.45d4d22c-232c-473e-9b15-9d9392c48cfa@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
 <4-0FPfF_TcDB7t9yJLz94MM7cPc77dtrMI9-p03O5pc=.45d4d22c-232c-473e-9b15-9d9392c48cfa@github.com>
Message-ID: <5Nw4daRUMKo4zKdiidcXAPovdy2dmjXILgFYDxxv9xY=.4702cc59-03ea-4178-b2f8-2767f1a23f47@github.com>

On Fri, 30 May 2025 09:06:00 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> p-nima has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   apply review feedback
>
> test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 113:
> 
>> 111:                 }
>> 112:                 e.printStackTrace();
>> 113:             }
> 
> AFAICT, you should be using `assertThrows` as follows:
> 
> 
> IOException exception = assertThrows(...);
> assertEquals(exception.message(), "too many authentication attempts. Limit: " + RETRY_LIMIT);
> assertEquals(requestCount.get(), RETRY_LIMIT > 0 ? RETRY_LIMIT : 1);

The changes have been made in 2d0325649e4d0f67e25aa30ba36c1c2555bc59b9- We decrement the request count because we authenticate the request at least once before the limit is checked. A call to math.max can be done but I think the ternary operator helps to reduce the overhead of the call, wdyt?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2132339249

From duke at openjdk.org  Fri Jun  6 14:58:47 2025
From: duke at openjdk.org (p-nima)
Date: Fri, 6 Jun 2025 14:58:47 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit
 of 3 retries [v3]
In-Reply-To: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
Message-ID: <YDBkhUM6CsyFC-R7BFtO3KllioNrEm4i8rIiugG02Qc=.777450cf-af08-4074-8f80-af3eb9c78cfb@github.com>

> 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 summary

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25490/files
  - new: https://git.openjdk.org/jdk/pull/25490/files/2d032564..24cc8944

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25490&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25490&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25490.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25490/head:pull/25490

PR: https://git.openjdk.org/jdk/pull/25490

From duke at openjdk.org  Fri Jun  6 14:58:48 2025
From: duke at openjdk.org (p-nima)
Date: Fri, 6 Jun 2025 14:58:48 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit
 of 3 retries [v3]
In-Reply-To: <Ne6MShrbDfh8xQbze1nkiz12CS8bu2iUJ2Q81K7xxgo=.5ff9f88b-7e1d-435e-bbb8-a19761b06421@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
 <4-0FPfF_TcDB7t9yJLz94MM7cPc77dtrMI9-p03O5pc=.45d4d22c-232c-473e-9b15-9d9392c48cfa@github.com>
 <Ne6MShrbDfh8xQbze1nkiz12CS8bu2iUJ2Q81K7xxgo=.5ff9f88b-7e1d-435e-bbb8-a19761b06421@github.com>
Message-ID: <Eq0VGcGQWCBew_NDHtivWFUDBc3_KrXm9OjGMDPK18w=.6868817e-675c-4b12-abba-885f12ecd531@github.com>

On Fri, 30 May 2025 15:01:03 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 57:
>> 
>>> 55: 
>>> 56: 
>>> 57: class HttpClientRetryLimitTest implements HttpServerAdapters {
>> 
>> Shall we rename this to `HttpClientAuthRetryLimit`, since [there are several other retry limits](https://docs.oracle.com/en/java/javase/23/docs/api/java.net.http/module-summary.html#jdk.httpclient.auth.retrylimit)?
>
> Sounds reasonable to rename - and fix the `@summary` in the jtreg headers too

This has been updated in 24cc89442f55434c6c9cc2f625981cd7e11eba45

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2132352498

From duke at openjdk.org  Fri Jun  6 15:23:59 2025
From: duke at openjdk.org (p-nima)
Date: Fri, 6 Jun 2025 15:23:59 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit
 of 3 retries [v3]
In-Reply-To: <4-0FPfF_TcDB7t9yJLz94MM7cPc77dtrMI9-p03O5pc=.45d4d22c-232c-473e-9b15-9d9392c48cfa@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
 <4-0FPfF_TcDB7t9yJLz94MM7cPc77dtrMI9-p03O5pc=.45d4d22c-232c-473e-9b15-9d9392c48cfa@github.com>
Message-ID: <j8kATbwXIRZTjbxtiU-8AhBrowm_9mpkOKBcIewOh_0=.05c56b0d-4d1a-4b04-9206-5fe8dfdea18e@github.com>

On Fri, 30 May 2025 14:42:11 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> p-nima has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update summary
>
> test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 64:
> 
>> 62:             "jdk.httpclient.auth.retrylimit", DEFAULT_RETRY_LIMIT);
>> 63: 
>> 64:     static Stream<HttpClient.Version> args() {
> 
> I think we should also test against with SSL and without SSL cases. See `HttpResponseLimitingTest.ServerClientPair` for inspiration.

We now test it with both the scenarios - 2d0325649e4d0f67e25aa30ba36c1c2555bc59b9

> test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 88:
> 
>> 86:             try (
>> 87:                 HttpClient client = HttpClient.newBuilder()
>> 88:                         .authenticator(new Authenticator() {
> 
> To ensure the client will fire the request using the protocol version of our preference, could you also pass `version` to the client builder too, please?

As we now set the version on the request, so we no longer need to set it on the client - 2d0325649e4d0f67e25aa30ba36c1c2555bc59b9

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2132392565
PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2132394794

From mullan at openjdk.org  Fri Jun  6 15:24:04 2025
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 6 Jun 2025 15:24:04 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are
 not being checked with default SunX509 key manager [v4]
In-Reply-To: <xvvfE1iwaZVaj8meVlXZ2iiaEeioyklVWIwUxkMmk8A=.5f16c35d-1e1e-4146-b04e-5abfc4493ed2@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <xvvfE1iwaZVaj8meVlXZ2iiaEeioyklVWIwUxkMmk8A=.5f16c35d-1e1e-4146-b04e-5abfc4493ed2@github.com>
Message-ID: <CaZiNFdMD6TYqA6jL9Xie7Wrh7eBMKJOTe2YzH7Lb5g=.2fb10149-9e55-489a-96b8-a6038e1d0098@github.com>

On Wed, 14 May 2025 18:16:13 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> 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.
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make the test run on TLSv1.3

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`.

src/java.base/share/classes/sun/security/ssl/X509KeyManagerConstraints.java line 170:

> 168:     }
> 169: 
> 170:     protected boolean isConstraintsDisabled() {

Make this private? Not sure why it would need to be overridden.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2132394682
PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2132187663

From duke at openjdk.org  Fri Jun  6 16:03:54 2025
From: duke at openjdk.org (p-nima)
Date: Fri, 6 Jun 2025 16:03:54 GMT
Subject: RFR: 8340182: Java HttpClient does not follow default retry limit
 of 3 retries [v3]
In-Reply-To: <4-0FPfF_TcDB7t9yJLz94MM7cPc77dtrMI9-p03O5pc=.45d4d22c-232c-473e-9b15-9d9392c48cfa@github.com>
References: <cnAZiq6wPJRPP9CDzHPWI5OIvePWMkzV0Zz6Bp8oWmk=.cb6ff6db-d195-48b5-ba22-195705ad8184@github.com>
 <4-0FPfF_TcDB7t9yJLz94MM7cPc77dtrMI9-p03O5pc=.45d4d22c-232c-473e-9b15-9d9392c48cfa@github.com>
Message-ID: <eUKTQoMLizthB1AosSLK-iRspUOs09DVlVTjqYYsc34=.5d4e1c09-ce04-4205-bb31-c127afef425b@github.com>

On Fri, 30 May 2025 09:08:46 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> p-nima has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update summary
>
> test/jdk/java/net/httpclient/HttpClientRetryLimitTest.java line 73:
> 
>> 71:     @ParameterizedTest
>> 72:     @MethodSource("args")
>> 73:     public void testDefaultSystemProperty(HttpClient.Version version) throws Exception {
> 
> I see you made the class package-private in 18bac9f. You could have additionally made the method package-private too.

I have changed it to default - Based on the junit [documentation](https://junit.org/junit5/docs/5.11.0/api/org.junit.jupiter.params/org/junit/jupiter/params/ParameterizedTest.html) we should not mark such methods as private or static


> @ParameterizedTest is used to signal that the annotated method is a parameterized test method.
> Such methods must not be private or static.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25490#discussion_r2132462294

From abarashev at openjdk.org  Fri Jun  6 16:21:59 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 6 Jun 2025 16:21:59 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are
 not being checked with default SunX509 key manager [v4]
In-Reply-To: <zVgwYqUGhLYWXk3JSCXc7rrm_wNtq_EW4FFRQp1BEYA=.b4d50963-ec2b-4191-a7f2-0ccf60fc2564@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <xvvfE1iwaZVaj8meVlXZ2iiaEeioyklVWIwUxkMmk8A=.5f16c35d-1e1e-4146-b04e-5abfc4493ed2@github.com>
 <zVgwYqUGhLYWXk3JSCXc7rrm_wNtq_EW4FFRQp1BEYA=.b4d50963-ec2b-4191-a7f2-0ccf60fc2564@github.com>
Message-ID: <r4AMd_4-pjf_PHIYI36I3WHc6FvcI2-bSGldzvhkGFg=.ed24ea21-3860-4d2d-81ea-16c00ced5959@github.com>

On Thu, 5 Jun 2025 19:31:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make the test run on TLSv1.3
>
> test/jdk/sun/security/ssl/X509KeyManager/PeerConstraintsCheck.java line 1:
> 
>> 1: /*
> 
> I am trying to figure out when the algorithm constraints are enabled, why the key isn't being selected. I don't see anywhere that you are setting the algorithm constraints property.
> 
> Please add some more comments explaining how the exception case occurs.

Hi @seanjmullan! This PR fixes both JDK-8353113 and JDK-8170706. So we have 2 new unit tests for each:

1. `AlgorithmConstraintsCheck`: tests JDK-8170706. BTW, I'm going to update the `@bug` tag in this test to `8170706`
2. `PeerConstraintsCheck`: tests JDK-8353113. No need to set any algorithm constraints because we test against the peer supported certificate signatures sent to us in "signature_algorithms"/"signature_algorithms_cert" extensions. I'll add a comment to this test with the explanation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2132486696

From abarashev at openjdk.org  Fri Jun  6 16:53:51 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 6 Jun 2025 16:53:51 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are
 not being checked with default SunX509 key manager [v4]
In-Reply-To: <CaZiNFdMD6TYqA6jL9Xie7Wrh7eBMKJOTe2YzH7Lb5g=.2fb10149-9e55-489a-96b8-a6038e1d0098@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <xvvfE1iwaZVaj8meVlXZ2iiaEeioyklVWIwUxkMmk8A=.5f16c35d-1e1e-4146-b04e-5abfc4493ed2@github.com>
 <CaZiNFdMD6TYqA6jL9Xie7Wrh7eBMKJOTe2YzH7Lb5g=.2fb10149-9e55-489a-96b8-a6038e1d0098@github.com>
Message-ID: <Dr8nXtVReKyM-yLEjr8LBerGUo-GjP_HhhmqTujd3S8=.44c27f3a-63ac-4b07-9e76-7c23b61c3d49@github.com>

On Fri, 6 Jun 2025 13:20:20 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make the test run on TLSv1.3
>
> src/java.base/share/classes/sun/security/ssl/X509KeyManagerConstraints.java line 170:
> 
>> 168:     }
>> 169: 
>> 170:     protected boolean isConstraintsDisabled() {
> 
> Make this private? Not sure why it would need to be overridden.

If we have a consensus on keeping `jdk.tls.keymanager.disableConstraintsChecking` toggle as is, then I'm going to remove this method and do this check directly in the constructor.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2132534993

From hchao at openjdk.org  Fri Jun  6 20:03:57 2025
From: hchao at openjdk.org (Hai-May Chao)
Date: Fri, 6 Jun 2025 20:03:57 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are
 not being checked with default SunX509 key manager [v3]
In-Reply-To: <Y5H3B2fG0QzzWergfvrhg7SRHQLEHj0DODFDaU1hnPQ=.10f836b6-63be-45ec-bf44-dd02108feb22@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <-ZEXFTVO7PI8Zi-swf24GBN2AzreQcNgviTSt5Je7wY=.53bc02bb-1532-4dad-a9f5-78da47587018@github.com>
 <7X6nIpKCnN0vyZl2CLNsLs8fcKRAaDlUdmNxz4vyPlA=.c74c7b36-ebec-4ff8-ac64-09589009b87e@github.com>
 <JGgkSA4koYf9fBlA0nf2qFXnw0AaPk7I0kiVpv6CPeI=.8e8221d1-5b21-4c8f-a821-253f3fe1c850@github.com>
 <Y5H3B2fG0QzzWergfvrhg7SRHQLEHj0DODFDaU1hnPQ=.10f836b6-63be-45ec-bf44-dd02108feb22@github.com>
Message-ID: <6zkY8S4cVr4HOiWkQlXuh3Vu0QXWzyB-buNY2_Wvpl0=.81e0a04e-a82f-4e46-82c1-88cb40d9603e@github.com>

On Thu, 15 May 2025 19:29:07 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> > > It is nice to refactor the common code for algorithm constraints checking into a new class, `X509KeyManagerConstraints.java`, used by both `SunX509KeyManagerImpl` and `X509KeyManagerImpl`. However, it looks like a new system property, "jdk.tls.keymanager.disableConstraintsChecking", is introduced, and it will affect both `SunX509KeyManagerImpl` and `X509KeyManagerImpl`. Should the property be a switch for SunX509 KeyManager, not a general toggle for all KeyManager? Avoiding its misuse for `X509KeyManagerImpl` that may lead to disable the existing RFC compliant algorithm constraints checking? It might be preferable to keep the property logic in `SunX509KeyManagerImpl` (not in the common code).
> > 
> > 
> > @haimaychao Thanks for looking into it! Yes, it will disable constraints checking for both key managers and I did it this way on purpose. I think it will be simpler and less confusing to the end users. This system property is off by default and my assumption is that if end users want to disable KM algorithm constraints checking they would expect it to be disabled system-wide. Making this toggle SunX509-specific is a trivial change if we have a consensus on this.
> > @seanjmullan What do you think?
> 
> Need to think about it some more, but I am kind of leaning towards it only affecting SunX509. The main benefit of the property is to workaround any compatibility issues where current code is not ready for the change. Any application already using the PKIX TrustManager already has this checking enabled/enforced.

I'd agree. As I mentioned in my earlier comment, if the new system property ends up toggling behavior in both `SunX509KeyManager` and `X509KeyManagerImpl`, we could run into an unintended side effect. While we're adding compliant algorithm constraints checking to `SunX509KeyManager`, turning on the property to disable it for compatibility reasons would also disable the already-existing checking in `X509KeyManagerImpl`. The applications already relying on the stricter checks in `X509KeyManagerImpl` might lose that enforcement unintentionally.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25016#issuecomment-2950663297

From abarashev at openjdk.org  Fri Jun  6 21:13:51 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 6 Jun 2025 21:13:51 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are
 not being checked with default SunX509 key manager [v4]
In-Reply-To: <CaZiNFdMD6TYqA6jL9Xie7Wrh7eBMKJOTe2YzH7Lb5g=.2fb10149-9e55-489a-96b8-a6038e1d0098@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <xvvfE1iwaZVaj8meVlXZ2iiaEeioyklVWIwUxkMmk8A=.5f16c35d-1e1e-4146-b04e-5abfc4493ed2@github.com>
 <CaZiNFdMD6TYqA6jL9Xie7Wrh7eBMKJOTe2YzH7Lb5g=.2fb10149-9e55-489a-96b8-a6038e1d0098@github.com>
Message-ID: <dUqp1eE1r7WCnvTsiskeeBEuRUO2MU8LgAHbZR53KQg=.779bbb42-784a-4f62-a29e-577fe40fb31b@github.com>

On Fri, 6 Jun 2025 15:20:56 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make the test run on TLSv1.3
>
> 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.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2132913338

From abarashev at openjdk.org  Fri Jun  6 21:21:52 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 6 Jun 2025 21:21:52 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are
 not being checked with default SunX509 key manager [v4]
In-Reply-To: <s3KKr3corBQNC4HO3LqGCPCvoEMf45X3Q3ch3aUCAE0=.86e1d246-19c1-4222-971f-50f2a96cda1f@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <xvvfE1iwaZVaj8meVlXZ2iiaEeioyklVWIwUxkMmk8A=.5f16c35d-1e1e-4146-b04e-5abfc4493ed2@github.com>
 <s3KKr3corBQNC4HO3LqGCPCvoEMf45X3Q3ch3aUCAE0=.86e1d246-19c1-4222-971f-50f2a96cda1f@github.com>
Message-ID: <EW0TYxe6HMEHe7iAFt3W70PGrm3ZpCy6cZhzWe1GR2Q=.00e86f02-0bd4-46dc-97b1-7f5c8b3173a9@github.com>

On Thu, 5 Jun 2025 17:40:28 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make the test run on TLSv1.3
>
> src/java.base/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java line 264:
> 
>> 262:      * the peer (if any).
>> 263:      *
>> 264:      * @since 1.5
> 
> I would remove the `@since 1.5` from these methods. It isn't relevant anymore since this is an internal class and that version is no longer supported. That version info is in the `X509ExtendedKeyManager` API which is sufficient.

Done.

> src/java.base/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java line 395:
> 
>> 393:                 if (SSLLogger.isOn && SSLLogger.isOn("keymanager")) {
>> 394:                     SSLLogger.fine("Ignore alias " + alias +
>> 395:                             ": certificate list does not conform to " +
> 
> suggest saying "certificate chain" not "certificate list".

Done. Also changing the same message in `X509KeyManagerImpl`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2132920769
PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2132919667

From abarashev at openjdk.org  Fri Jun  6 23:22:52 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 6 Jun 2025 23:22:52 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are
 not being checked with default SunX509 key manager [v4]
In-Reply-To: <s3KKr3corBQNC4HO3LqGCPCvoEMf45X3Q3ch3aUCAE0=.86e1d246-19c1-4222-971f-50f2a96cda1f@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <xvvfE1iwaZVaj8meVlXZ2iiaEeioyklVWIwUxkMmk8A=.5f16c35d-1e1e-4146-b04e-5abfc4493ed2@github.com>
 <s3KKr3corBQNC4HO3LqGCPCvoEMf45X3Q3ch3aUCAE0=.86e1d246-19c1-4222-971f-50f2a96cda1f@github.com>
Message-ID: <gcFQMFOoDfItWveSNHHS_NcV5dqK4EdvUh556otCgsQ=.ab3ae941-5a95-43fb-a541-a7e280cd6346@github.com>

On Thu, 5 Jun 2025 15:10:35 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make the test run on TLSv1.3
>
> test/lib/jdk/test/lib/security/CertificateBuilder.java line 244:
> 
>> 242:      * @throws IOException if an encoding error occurs.
>> 243:      */
>> 244:     public CertificateBuilder addSubjectAltNameIPExt(List<String> IPAddresses)
> 
> variables usually start with lower case letter, so suggest `ipAddresses`

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2133067693

From abarashev at openjdk.org  Fri Jun  6 23:34:52 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 6 Jun 2025 23:34:52 GMT
Subject: RFR: 8353113: Peer supported certificate signature algorithms are
 not being checked with default SunX509 key manager [v4]
In-Reply-To: <zVgwYqUGhLYWXk3JSCXc7rrm_wNtq_EW4FFRQp1BEYA=.b4d50963-ec2b-4191-a7f2-0ccf60fc2564@github.com>
References: <-vJhrfGwnLPedP_wFNR6ihKbh_jbANgqrinbnGHYNxc=.d41c36bc-c9bf-4986-9f3a-e5e5ddeae95f@github.com>
 <xvvfE1iwaZVaj8meVlXZ2iiaEeioyklVWIwUxkMmk8A=.5f16c35d-1e1e-4146-b04e-5abfc4493ed2@github.com>
 <zVgwYqUGhLYWXk3JSCXc7rrm_wNtq_EW4FFRQp1BEYA=.b4d50963-ec2b-4191-a7f2-0ccf60fc2564@github.com>
Message-ID: <3EASChBurpIG_iq35iGkr7MYrc79c0jl_RNb7sbqYkk=.65d9df1a-9e96-4e8e-a409-c9f9d7eef597@github.com>

On Thu, 5 Jun 2025 19:00:27 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make the test run on TLSv1.3
>
> test/jdk/sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java line 1:
> 
>> 1: /*
> 
> Are these changes relevant to this issue? It doesn't use a SunX509 TrustManager AFAICT.

You mean `SunX509` KeyManager? All these existing tests I'm modifying in this PR are using it together with the certificates signed with `MD5withRSA` algorithm. That's why they fail when we add algorithm constraints to SunX509KeyManagerImpl - MD5 is not allowed in TLSv1.3.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25016#discussion_r2133073579