sdk-http-vertx: cap and expose MaxConcurrentStreams (default Integer.MAX_VALUE concentrates fan-in onto one event-loop)

[tillrohrmann]

Problem

RestateHttpServer.DEFAULT_OPTIONS configures HTTP/2 with no cap on concurrent streams:

private static final HttpServerOptions DEFAULT_OPTIONS =
    new HttpServerOptions()
        .setInitialSettings(new Http2Settings().setMaxConcurrentStreams(Integer.MAX_VALUE));

Vert.x pins each accepted HTTP/2 connection to one event-loop thread for the connection's lifetime, and all streams multiplexed on that connection serialize on that thread. Evidence in this codebase:

• HttpEndpointRequestHandler extracts the per-connection context via ((HttpServerRequestInternal) request).context(), and the per-request executor re-enters that same context via ctx.runOnContext(runnable) (HttpEndpointRequestHandler.java:102-105). This guarantees every stream's state-machine syscalls run on the connection's pinned event loop.
• Vert.x's standard HttpServer model (see Advanced Vert.x Guide — Threading) pins each accepted connection to a single event-loop context for its lifetime.

With MaxConcurrentStreams = Integer.MAX_VALUE a single HTTP/2 connection can multiplex arbitrarily many concurrent streams, all of which then serialize on one thread. Under load this concentrates fan-in rather than spreading it across the available event loops. Most other HTTP/2 server defaults are far smaller for this reason (Node's http2 default: 100; gRPC-Java default: ~100).

Proposal

1. Lower the default setMaxConcurrentStreams(...) to a sensible value (e.g. 100, matching common HTTP/2 server defaults).
2. Expose the knob on the endpoint builder so users who genuinely want unbounded multiplexing per connection can opt in.

The existing RestateHttpServer.from*(...) overloads already accept a user-supplied HttpServerOptions, so opting in to a higher cap is already possible — but most users won't pass custom options, and the current shipped default is the surprising one.

Files

• sdk-http-vertx/src/main/java/dev/restate/sdk/http/vertx/RestateHttpServer.java (line 46-48 for DEFAULT_OPTIONS).

Context

Surfaced while investigating an intermittent InvokerMemoryTest failure in the Restate e2e suite. That specific failure had a different root cause (testcontainers' host-port relay), but the MaxConcurrentStreams=Integer.MAX_VALUE default came up repeatedly as a separate hardening item: nothing in the SDK protects users from a peer fanning N streams onto a single event-loop thread.

[slinkydeveloper]

Lower the default setMaxConcurrentStreams(...) to a sensible value (e.g. 100, matching common HTTP/2 server defaults).|

As said here https://restatedev.slack.com/archives/C04KZRLE1SM/p1780472059000269, now that we have the connection pool, we should reconsider some of these defaults.

Expose the knob on the endpoint builder so users who genuinely want unbounded multiplexing per connection can opt in.

The knob is already exposed by creating the server yourself, no action needed there.

[slinkydeveloper]

I consider this done, we have changed the defaults going back to normal vertx defaults instead of maxing ou max concurrent streams, and the knob is exposed by building your own server.