-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
InvocationType improvements and cleanups #12266
Labels
Bug
For general bugs on Jetty side
Comments
sbordet
added a commit
that referenced
this issue
Sep 13, 2024
* Removed usages of `AbstractConnection.getInvocationType()`. * Changed HTTP server-side Connection implementations to use `AbstractConnection.fillInterested(Callback)` with a callback that specifies the `InvocationType`, derived from the `Server`, which derives it from the `Handler` chain. * Changed client-side receivers to use `AbstractConnection.fillInterested(Callback)` with a callback that specifies the `InvocationType`, derived from the `HttpClientTransport`. * Introduced `HttpClientTransport.getInvocationType(Connection)`, so that client applications can specify whether they block or not. * Made sure client-side HTTP/2 and HTTP/3 return tasks with the proper `InvocationType` to be run by the `ExecutionStrategy` when calling application code. * HTTP3StreamConnection now uses an `EITHER` fillable callback to possibly process streams in parallel. * `QuicStreamEndPoint` now uses a task to invoke `FillInterest.fillable()`, rather than invoking it directly, therefore honoring the `InvocationType` of callback set by the `Connection` associated with the `QuicStreamEndPoint`. Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
sbordet
added a commit
that referenced
this issue
Sep 23, 2024
* Removed usages of `AbstractConnection.getInvocationType()`. * Changed HTTP server-side Connection implementations to use `AbstractConnection.fillInterested(Callback)` with a callback that specifies the `InvocationType`, derived from the `Server`, which derives it from the `Handler` chain. * Changed client-side receivers to use `AbstractConnection.fillInterested(Callback)` with a callback that specifies the `InvocationType`, derived from the `HttpClientTransport`. * Introduced `HttpClientTransport.getInvocationType(Connection)`, so that client applications can specify whether they block or not. * Made sure client-side HTTP/2 and HTTP/3 return tasks with the proper `InvocationType` to be run by the `ExecutionStrategy` when calling application code. * HTTP3StreamConnection now uses an `EITHER` fillable callback to possibly process streams in parallel. * `QuicStreamEndPoint` now uses a task to invoke `FillInterest.fillable()`, rather than invoking it directly, therefore honoring the `InvocationType` of callback set by the `Connection` associated with the `QuicStreamEndPoint`. Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
This was referenced Oct 2, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Jetty version(s)
12
Description
On the server, the
InvocationType
of aHandler
controls how Jetty invokes theHandler
chain.On the client, instead, the
InvocationType
is hardcoded to beBLOCKING
for HTTP/1.1, a mix of undefined,BLOCKING
andNON_BLOCKING
for HTTP/2 and HTTP/3.There should be an option on the client to allow applications to specify the invocation type, with consistent defaults across transports if not specified.
With the occasion, we should also get rid of the deprecated
AbstractConnection.getInvocationType()
.The text was updated successfully, but these errors were encountered: