On 01.04.2026 05:49, Ryan Schmitt wrote:
On Fri, Mar 27, 2026 at 10:00 AM Oleg Kalnichevski <[email protected]> wrote:
There is absolutely no guarantee there is a way to build a reasonable
HTTP/2 transport using classic i/o given its nature and inherent
limitations. If one ends up having to have a dedicated thread per H2
stream it is not going to work and scale well no matter how cheap
virtual threads are.
I agree that HTTP/2 is the sticking point due multiplexing and support for
full-duplex streaming. However, keep in mind that Go implements HTTP/2
exactly as you're describing. There's a connection-level read loop that
does blocking frame reads and dispatches frames to the appropriate stream:
https://github.com/golang/go/blob/4f62ef0625628e52d56779803805ca125ce34230/src/net/http/internal/http2/transport.go#L2097
And the write path similarly spawns a goroutine that writes the request and
then waits for the response:
https://github.com/golang/go/blob/4f62ef0625628e52d56779803805ca125ce34230/src/net/http/internal/http2/transport.go#L1310
This doesn't translate directly to Java since Go's `select` statement is
inherently multiplexed and can block on multiple channels simultaneously
(closest thing we have is `CompletableFuture.anyOf()` from Java 9), but
it's an interesting proof-of-concept for an HTTP/2 implementation built
entirely on stackful coroutines.
We also have the option of retaining the event loop for connection-level
code, while migrating higher-level code in the async client (such as route
establishment) to the blocking implementation used by the classic
transport. The point is that virtual threads are a huge opportunity to
consolidate the classic and async implementations, and we're mainly limited
by the performance of virtual threads compared to the callback-based
implementation.
I have spent several days thinking about it and I am beginning to like
the idea of an unified high level protocol layer on top of the classic
and async core transports more and more. I doubt though we could just
re-use the existing classic code because it is inherently coupled with
the InputStream / OutputStream abstraction. But I would really love to
have just a single execution pipeline implementation instead of two. So,
it is worth investing some thinking and some efforts into it.
I understand that Amazon has no interest in our server-side components.
That is fine. This proposal however directly conflicts with the
project's charter however outdated it is these days. You will have to
start off by drafting a new charter, getting it voted upon and
approved. One should also consider dropping `HttpComponents` name as no
longer reflective of the project scope and purpose and re-branding it
back as `HttpClient` as it originally was prior to the year 2005.
If people are getting use out of the server-side components then I don't
want to drop them. What I *do* want is to make the core-client boundary
easier to maintain, if possible. We have a lot of heavily overloaded
methods and constructors and so on in order to preserve core's ABI
compatibility with older versions of client. I'm not sure what to do about
this.
I personally do not see how throwing everything into a single project
with a single release cycle would make any difference here. The only
person presently hurt by having to manage separate release cycles for
core and client is me, as their release manager. The separation of core
and client has many benefits. Why would we want to throw it all away?
Just to spare an extra trouble having to import two modules into a
single IntelliJ project?
Would the existing charter allow us to consolidate core and client into a
single repository and release train? Lockstep versioning of the core and
client modules might allow us to relax backwards compatibility for
the @Internal APIs in core.
How would a single repository make any difference with regards internal
APIs? @Internal is a just a way of marking classes with public
visibility as having different contract when they cannot be made package
private.
I really have a problem understanding your motives here.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
