Issue #12266 - InvocationType improvements and cleanups. #12596
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is the work for the client-side. Now the `InvocationType` can be specified at the `HttpClientTransport` level, or at the `ClientConnectionFactory.Info` level (for the dynamic transport). Wired the `InvocationType` also for `Response.ContentSourceListener`, so that for applications that read response content using `Content.Source` and specify an `InvocationType` to `demand(Runnable)`, the implementation will honor it. Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
Simplified retrieval of InvocationType, now only available from the HttpClientTransport. Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
…case of content not yet arrived. Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
Before, `Stream.Listener.onHeaders()` was assuming that the headers were processed synchronously. Now, `HttpReceiverOverHTTP2` process them asynchronously, with a task that declares an invocation type. This was causing a race between the task and the code present after the call to `onHeaders()`. Introduced `Stream.Listener.onHeaders(Stream, HeadersFrame, Callback)` to allow asynchronous processing of `HeadersFrame`s. Optimised `HttpReceiver.responseHeaders()` to avoid creating the `Content.Source` if there is no content. Fixed `IteratingCallback` and `HTTP2Flusher` to use `tryLock()` in `toString()` to avoid deadlocks. Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
…type-cleanups'. Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
lorban
requested changes
Dec 4, 2024
jetty-core/jetty-client/src/main/java/org/eclipse/jetty/client/HttpClientTransport.java
Show resolved
Hide resolved
jetty-core/jetty-client/src/main/java/org/eclipse/jetty/client/transport/HttpReceiver.java
Outdated
Show resolved
Hide resolved
jetty-core/jetty-client/src/main/java/org/eclipse/jetty/client/Response.java
Outdated
Show resolved
Hide resolved
...tty-client/src/main/java/org/eclipse/jetty/client/transport/HttpClientTransportOverHTTP.java
Outdated
Show resolved
Hide resolved
...ort/src/main/java/org/eclipse/jetty/http2/client/transport/HttpClientTransportOverHTTP2.java
Outdated
Show resolved
Hide resolved
...ort/src/main/java/org/eclipse/jetty/http3/client/transport/HttpClientTransportOverHTTP3.java
Outdated
Show resolved
Hide resolved
...rt/src/main/java/org/eclipse/jetty/http3/client/transport/internal/HttpChannelOverHTTP3.java
Show resolved
Hide resolved
jetty-core/jetty-server/src/main/java/org/eclipse/jetty/server/internal/HttpChannelState.java
Show resolved
Hide resolved
...ent-transports/src/test/java/org/eclipse/jetty/test/client/transport/VirtualThreadsTest.java
Show resolved
Hide resolved
jetty-core/jetty-util/src/main/java/org/eclipse/jetty/util/IteratingCallback.java
Show resolved
Hide resolved
…type-cleanups'. Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
…type-cleanups'. Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
…type-cleanups'. Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
Fixed reset race in HTTP2Stream. Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
…type-cleanups'. Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
For HTTP/2, the response may have arrived, but the exchange failed (due to the request being failed); in this case, we want to notify an UpgradeException, not a generic Exception. Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
lorban
requested changes
Jan 6, 2025
...y-client/src/main/java/org/eclipse/jetty/client/transport/internal/ProtocolHttpUpgrader.java
Show resolved
Hide resolved
...t/src/main/java/org/eclipse/jetty/http2/client/transport/internal/HttpReceiverOverHTTP2.java
Show resolved
Hide resolved
...t/src/main/java/org/eclipse/jetty/http2/client/transport/internal/HttpReceiverOverHTTP2.java
Show resolved
Hide resolved
Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
lorban
approved these changes
Jan 6, 2025
gregw
approved these changes
Jan 6, 2025
| // Ask the InvocationType to the Content.Source, where applications | ||
| // have set it there using Content.Source.demand(Runnable). | ||
| Invocable.InvocationType invocationType = Invocable.getInvocationType(contentSource); | ||
| Runnable demandCallback = Invocable.from(invocationType, () -> onContentSource(response, contentSource)); |
There was a problem hiding this comment.
I think we can improve Invocable.from so that for any Runnable passed in that is not Invocable, it will not wrap with a ReadyTask if the type is BLOCKING.
| @Override | ||
| public InvocationType getInvocationType() | ||
| { | ||
| return Invocable.getInvocationType(contentSource); |
There was a problem hiding this comment.
Is it worthwhile working this out once when the contentSource is set?
Probably not... but maybe???
| @Override | ||
| public InvocationType getInvocationType() | ||
| { | ||
| return Invocable.getInvocationType(source); |
There was a problem hiding this comment.
source is final, so perhaps work this out in the constructor?
There was a problem hiding this comment.
We can't make it a constant because Content.Source delegates the InvocationType to the demand callback that may change across invocations of demand(Runnable) -- although admittedly rare.
This was referenced Jan 15, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is the work for the client-side.
Now the
InvocationTypecan be specified at theHttpClientTransportlevel, or at theClientConnectionFactory.Infolevel (for the dynamic transport).Wired the
InvocationTypealso forResponse.ContentSourceListener, so that for applications that read response content usingContent.Sourceand specify anInvocationTypetodemand(Runnable), the implementation will honor it.