On Tue, 2 Dec 2025 16:53:23 GMT, Daniel Fuchs <[email protected]> wrote:
> The `jdk.httpclient.quic.maxBidiStreams` is an undocumented system property > only used in tests. This property is only useful to control the default > HTTP/3 test server implementation. It will never be documented or exposed. It > should be clearly labelled as internal. > The HTTP/3 client always provide a value of 0 for the > `initial_max_streams_bidi` transport parameter, so the default value that the > quic stack uses internally to set the parameter if no value is provided is > never used on the client side. > > The `H3StreamLimitReachedTest` can be used to verify the change - it won't > pass if the property is not correctly configured in the test. > > I have also taken this opportunity to add comments to the > `H3StreamLimitReachedTest` and the `StreamLimitTest`, to explain the logic of > each test. > > With this I believe that we can also say that this change will fix > [JDK-8365794](https://bugs.openjdk.org/browse/JDK-8365794). src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicConnectionImpl.java line 179: > 177: // The default value for the max_idle_timeout transport parameter > that a QuicConnectionImpl > 178: // will send to its peer, if no value is provided by the higher > level protocol. > 179: public static final int DEFAULT_MAX_INITIAL_TIMEOUT = Math.clamp( Hello Daniel, I think this comment is an oversight. This `DEFAULT_MAX_INITIAL_TIMEOUT` and the corresponding property control the maximum amount of time we wait for the connection attempt, against a server, to respond with an `INITIAL` packet. It doesn't control the idle timeout transport parameter. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28611#discussion_r2584956772
