Skip to content

Allow configurable additional http2 connections - #660

Open
ymo-sci wants to merge 5 commits into
mainfrom
feature/ymo/SE-15483-additional-http2-connections
Open

ymo-sci wants to merge 5 commits into
mainfrom
feature/ymo/SE-15483-additional-http2-connections

Conversation

@ymo-sci

@ymo-sci ymo-sci commented Oct 29, 2026

Copy link
Copy Markdown
Contributor

Description

only added for emergency cases to be activatable with a simple restart via config.

Additional Notes

  • This PR fixes or works on following ticket(s): SE-15483
  • This PR is related to PR:

Checklist

  • Code change has been tested and works locally
  • Code was formatted via IntelliJ and follows SonarLint & best practices
  • Patch Tasks: Is local execution of Patch Tasks necessary? If so, please also mark the PR with the tag.

The JDK HttpClient maintains a single HTTP/2 connection per server and
client. Once the server-side limit of concurrent streams
(SETTINGS_MAX_CONCURRENT_STREAMS) is reached, further requests fail
immediately with "too many concurrent streams" - the client neither
waits for a free stream nor opens another connection.

A block in http.outcall.timeouts can now permit additional connections
for this case via "maxAdditionalConnections". If permitted, such a
request is sent via one of up to this many additional clients of its
client selector instead of failing right away. As the stream could not
be reserved, the request has not been sent yet and can safely be sent
again. If all connections are exhausted, the request fails as before.
Slow responses are still handled by the timeouts and the blacklist.

This is disabled by default (maxAdditionalConnections = 0) and only
takes effect for outcalls using a client selector.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

- fixes: SE-15483
The key is always present due to the default block, so it can be read
directly from the extension config. Non-positive values disable
additional connections.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

- fixes: SE-15483
@ymo-sci ymo-sci added 🧬 Enhancement Contains new features 🤖 AI-Assisted Created with significant assistance of artificial intelligence tools labels Oct 29, 2026
Copilot AI balanced review requested due to automatic review settings October 29, 2026 09:47

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Changes recommended

Newly added clients can fail without retrying after a stream-limit race, and shared client reuse can exceed the current call’s configured additional-connection limit.

2 open issues
What changed in this PR

Adds an opt-in fallback for outbound HTTP/2 requests that hit a server’s concurrent-stream limit, intended for emergency use through configuration and a restart.

Changes:

  • Adds maxAdditionalConnections, disabled by default.
  • Caches additional HTTP clients per selector and retries requests after stream-limit failures.
  • Documents the fallback behavior and logs additional client creation.
File Description
src/​main/​resources/​component-050-kernel.conf Defines and documents the default additional-connection limit.
src/​main/​java/​sirius/​kernel/​commons/​Outcall.java Loads the limit and adds client caching, fallback sends, and logging.

Review effort: Balanced

The additional clients are shared per client selector, while the limit
is configured per call - only use as many of them as the current call
permits. Also try a newly added client within the retry loop, as other
requests might occupy its streams before the creating request is sent.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔵 Needs a closer look

Reassigning client causes subsequent redirects and OAuth retries to try a saturated additional client twice while skipping an available primary, leading to avoidable request failures.

No open issues 🎉

1 previously missed issue

In code that hasn't changed since last review

Medium severity Keep the primary client as the starting client for retries

src/​main/​java/​sirius/​kernel/​commons/​Outcall.java:656

Assigning the additional client to client also makes it the starting client for subsequent redirects and OAuth retries. With one additional client, a follow-up request fails if that client's connection is saturated, even when the primary has capacity, because it tries the additional client twice and never tries the primary. Use a local variable for the additional send so the primary remains the starting client.

2 resolved since last review

Review effort: Balanced

…ional connections

The additional client is no longer stored in the client field, so that redirects and the OAuth retry
start with the cached client again instead of re-trying a possibly exhausted additional client.

Also documents that this bypasses the server's stream limit and should only be enabled in coordination
with its operator, that additional clients are kept until the JVM is restarted, and that the feature has
no effect via the deprecated withConfiguredTimeout(String) or without a configured connectTimeout.

- fixes: SE-15483
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

🤖 AI-Assisted Created with significant assistance of artificial intelligence tools 🧬 Enhancement Contains new features

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants