Implement Eclipse Jetty core HTTP handler adapter #32097

gregw · 2024-01-24T06:08:57Z

This provides an implementation of a HTTP Handler Adaptor that is coded directly to the Eclipse Jetty core API, bypassing any servlet implementation.

Fixes #32035

pivotal-cla · 2024-01-24T06:09:53Z

@gregw Please sign the Contributor License Agreement!

Click here to manually synchronize the status of this Pull Request.

See the FAQ for frequently asked questions.

gregw · 2024-01-24T08:05:02Z

@pivotal-cla Working on getting a CCLA signed. Stand by....

.../main/java/org/springframework/web/reactive/function/server/DefaultServerRequestBuilder.java

gregw · 2024-02-01T01:42:02Z

@lachlan-roberts can you sign the individual CLA.

gregw · 2024-02-01T01:43:44Z

This PR is failing 2 tests that undertow also fails: See #25310.
Thus I'm currently suspecting bad tests or a spring bug, as both Jetty core and undertow are similar fully asynchronous integrations without servlets. We will investigate more, but any ideas that can help...

pivotal-cla · 2024-02-01T01:46:58Z

@gregw Thank you for signing the Contributor License Agreement!

...-web/src/main/java/org/springframework/http/server/reactive/JettyCoreServerHttpResponse.java

gregw · 2024-02-01T02:32:03Z

spring-web/src/main/java/org/springframework/http/server/reactive/JettyRetainedDataBuffer.java

+		// this.dataBuffer = dataBufferFactory.wrap(BufferUtil.copy(chunk.getByteBuffer())); // TODO this copy avoids multipart bugs
+		this.dataBuffer = dataBufferFactory.wrap(chunk.getByteBuffer()); // TODO avoid double slice?


This is the work around for the failing multipart tests (see #25310)

...g-web/src/main/java/org/springframework/http/server/reactive/JettyCoreServerHttpRequest.java

…pResponse Signed-off-by: Lachlan Roberts <lachlan@webtide.com>

…HttpResponse Signed-off-by: Lachlan Roberts <lachlan@webtide.com>

Signed-off-by: Lachlan Roberts <lachlan.p.roberts@gmail.com>

upgrade jetty

Signed-off-by: Lachlan Roberts <lachlan.p.roberts@gmail.com>

poutsma · 2024-06-06T09:40:16Z

I have committed several other changes, see https://github.com/poutsma/spring-framework/commits/gh-32097/.

The only test that fails is the MultipartWebClientIntegrationTests. It does not fail in the IDE, making it a bit harder to reproduce. This is the server-side stack trace I get:

java.lang.IllegalArgumentException: demand pending
    at org.eclipse.jetty.server.internal.HttpChannelState$ChannelRequest.demand(HttpChannelState.java:955) ~[jetty-server-12.0.10.jar:12.0.10]
    at org.eclipse.jetty.io.content.ContentSourcePublisher$SubscriptionImpl.process(ContentSourcePublisher.java:124) ~[jetty-io-12.0.10.jar:12.0.10]
    at org.eclipse.jetty.util.thread.SerializedInvoker$Link.run(SerializedInvoker.java:191) [jetty-util-12.0.10.jar:12.0.10]
    at org.eclipse.jetty.server.internal.HttpConnection$DemandContentCallback.succeeded(HttpConnection.java:680) [jetty-server-12.0.10.jar:12.0.10]
    at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:99) [jetty-io-12.0.10.jar:12.0.10]
    at org.eclipse.jetty.io.SelectableChannelEndPoint$1.run(SelectableChannelEndPoint.java:53) [jetty-io-12.0.10.jar:12.0.10]
    at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:979) [jetty-util-12.0.10.jar:12.0.10]
    at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.doRunJob(QueuedThreadPool.java:1209) [jetty-util-12.0.10.jar:12.0.10]
    at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1164) [jetty-util-12.0.10.jar:12.0.10]
    at java.base/java.lang.Thread.run(Thread.java:840) [?:?]

@gregw Does that ring any bell with you, or are we doing something wrong in the Spring code?

I have also asked @rstoyanchev and @simonbasle to review (my branch of) the PR, so comments from them might be forthcoming.

The next Spring Framework milestone (6.2.0-M4) is on June 13th. I am not sure if we will have resolved the test above by that point, so this PR might not make that milestone. The milestone after that is scheduled for July 11th.

simonbasle · 2024-06-06T14:59:54Z

...lux/src/main/java/org/springframework/web/reactive/socket/adapter/JettyWebSocketSession.java

+
+	private final Flux<WebSocketMessage> flux;
+	private final Sinks.One<CloseStatus> closeStatusSink = Sinks.one();
+	private final Lock lock = new ReentrantLock();


This Lock got my attention because pessimistic locking is usually not the first go-to method in Reactive Streams. Instead it's usually some sort of optimistic locking with a CAS loop.

That said, the lock protects 2 critical sections that represent quick state checks and updates. There is precedent for that sort of things, e.g. in Reactor, so in that case I think it is fine (although care will need to be exercised if the code is modified or new usage of the lock is introduced).

simonbasle · 2024-06-06T15:01:51Z

...lux/src/main/java/org/springframework/web/reactive/socket/adapter/JettyWebSocketSession.java

+				boolean demand = false;
+				this.lock.lock();
+				try {
+					this.requested += n;


this is more problematic, as n can be an "unbounded request" (Integer.MAX_VALUE) and this.requested can overflow to negative.

Suggested change

this.requested += n;

this.requested += n;

if (this.requested < 0L) {

this.requested = Long.MAX_VALUE;

}

Using Math.addExact(long,long) is probably best.

simonbasle · 2024-06-06T15:07:29Z

...lux/src/main/java/org/springframework/web/reactive/socket/adapter/JettyWebSocketSession.java

+				try {
+					this.requested += n;
+					if (!this.awaitingMessage && this.requested > 0) {
+						this.requested--;


I'm not entirely sure how it translates in terms of getDelegate().demand() calls, but if the requested amount is unbounded, this decrement shouldn't happen.

with the above suggested change, unbounded request amount (n == Integer.MAXVALUE at any point) leads to this.requested == Long.MAX_VALUE so if that's the case the this.requested-- decrement should be skipped.

simonbasle · 2024-06-06T15:08:28Z

...lux/src/main/java/org/springframework/web/reactive/socket/adapter/JettyWebSocketSession.java

+			}
+			this.awaitingMessage = false;
+			if (this.requested > 0) {
+				this.requested--;


same as above, this should take the "unbounded request" scenario (in the Reactive Streams sense) into consideration

gregw · 2024-06-11T00:36:31Z

My apologies for being slow now... I've seen your reviews and will respond in the next few days.

rstoyanchev

There are a number of additional commits in the branch referenced from #32097 (comment), so do have a look there for the latest.

I've added a few comments and questions below. The only other thing to mention is we'll need a non-reactive variant of JettyWebSocketClient in the spring-websocket module for those who prefer not to use or have spring-webflux on the classpath.

...-web/src/main/java/org/springframework/http/server/reactive/JettyCoreServerHttpResponse.java

rstoyanchev · 2024-06-10T11:39:42Z

...-web/src/main/java/org/springframework/http/server/reactive/JettyCoreServerHttpResponse.java

+
+	@Override
+	protected Mono<Void> writeAndFlushWithInternal(Publisher<? extends Publisher<? extends DataBuffer>> body) {
+		return Flux.from(body).flatMap(this::writeWithInternal, 1).then();


This is supposed to flush after each nested Publisher, e.g. to ensure events in SSE stream are sent at the right time. Is there anything to ensure that? Nothing obvious that I see.

Jetty writes at this level are non-buffering. Any aggregation that might require flushing is done at a higher level. Now, we might actually buffer (e.g. if sitting in a flow control congested HTTP/2 stream), but if so, then flushing is not going to help.

The only time we really need a flush semantic is if there is no content at all, then we will write an empty buffer, so that at least the HTTP response headers are generated etc. So perhaps this method needs to detect if the body was actually empty, in which case an empty buffer should be written

rstoyanchev · 2024-06-10T11:47:34Z

...-web/src/main/java/org/springframework/http/server/reactive/JettyCoreServerHttpResponse.java

+
+		private final long length;
+
+		private long totalRead = 0;


All fields in this private IteratingCallback are Jetty types. I'm wondering if it makes sense for this to be in Jetty for wider availability?

Good idea. It might be in a slightly different form... probably something like:

Content.copy(Content.Source.from(channel, position, count), this.response, callback);

I'll try to get that in this months release.

rstoyanchev · 2024-06-10T11:50:34Z

.../org/springframework/web/testfixture/http/server/reactive/bootstrap/JettyCoreHttpServer.java

+		this.jettyServer.setHandler(createHandlerAdapter());
+
+		// TODO: We don't actually want the upgrade handler but this will create the WebSocketContainer.
+		//  This requires a change in Jetty.


It would be useful to add an issue link to track the change?

@lachlan-roberts

rstoyanchev · 2024-06-11T10:19:32Z

...lux/src/main/java/org/springframework/web/reactive/socket/adapter/JettyWebSocketSession.java

 *
 * @author Violeta Georgieva
 * @author Rossen Stoyanchev
 * @since 5.0
 */
-public class JettyWebSocketSession extends AbstractListenerWebSocketSession<Session> {
+@SuppressWarnings("NullAway")
+public class JettyWebSocketSession extends AbstractWebSocketSession<Session> {


I'm wondering about the choice to extend AbstractWebSocketSession rather than AbstractListenerWebSocketSession which implements the receiving logic. This relates to @simonbasle's question as well with the resulting implementation using a Lock.

@lachlan-roberts
can you look at the websocket part of these review

gregw · 2024-06-12T00:26:00Z

@poutsma Our branches have diverged as I made the changes to use AbstractServerHttpRequest and AbstractServerHttpResponse in my branch and you forked before that. Let me see if I can rebase yours onto mine....

…ettyCoreHttpHandlerAdapter # Conflicts: # spring-web/src/main/java/org/springframework/http/server/reactive/DefaultServerHttpRequestBuilder.java # spring-web/src/main/java/org/springframework/http/server/reactive/JettyCoreHttpHandlerAdapter.java # spring-web/src/main/java/org/springframework/http/server/reactive/JettyCoreServerHttpRequest.java # spring-web/src/main/java/org/springframework/http/server/reactive/JettyCoreServerHttpResponse.java # spring-webflux/src/main/java/org/springframework/web/reactive/socket/adapter/JettyWebSocketHandlerAdapter.java # spring-webflux/src/main/java/org/springframework/web/reactive/socket/adapter/JettyWebSocketSession.java # spring-websocket/src/main/java/org/springframework/web/socket/adapter/jetty/JettyWebSocketHandlerAdapter.java

…dapter

gregw · 2024-06-12T00:58:07Z

Actually, I'm not exactly sure why our branches were seen as divergent. I've merged yours back to mine and made sure that there are no differences, and also merged to lastest origin/main.
I'm not 100% sure the merge is correct, so we may want to proceed with your branch, but at least we can see your changes in this PR and I can work with it as well. Now looking at the test failure....

gregw · 2024-06-12T01:44:44Z

@poutsma

The only test that fails is the MultipartWebClientIntegrationTests. It does not fail in the IDE, making it a bit harder to reproduce. This is the server-side stack trace I get:
java.lang.IllegalArgumentException: demand pending
  ...
@gregw Does that ring any bell with you, or are we doing something wrong in the Spring code?

I think it is likely a problem with the jetty ContentSourcePublisher, for which we already have a PR in review: jetty/jetty.project#11849

The next Spring Framework milestone (6.2.0-M4) is on June 13th. I am not sure if we will have resolved the test above by that point, so this PR might not make that milestone. The milestone after that is scheduled for July 11th.

Agreed we are not making the 13th. We have a jetty release at the end of the month, so I will get #11849 merged for that and also look at change @rstoyanchev made.

@lachlan-roberts can you look at the websocket reviews before end of month, so that any changes needed in next jetty release can be included. E.g. anything needed to get the Container without the Handler

gregw mentioned this pull request Jan 24, 2024

Jetty core Handler that wraps Spring HttpHandler as an adaptor webtide/spring-framework#1

Closed

spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Jan 24, 2024

gregw commented Jan 31, 2024

View reviewed changes

.../main/java/org/springframework/web/reactive/function/server/DefaultServerRequestBuilder.java Outdated Show resolved Hide resolved

gregw marked this pull request as ready for review February 1, 2024 01:52

gregw commented Feb 1, 2024

View reviewed changes

...-web/src/main/java/org/springframework/http/server/reactive/JettyCoreServerHttpResponse.java Outdated Show resolved Hide resolved

gregw commented Feb 1, 2024

View reviewed changes

...g-web/src/main/java/org/springframework/http/server/reactive/JettyCoreServerHttpRequest.java Outdated Show resolved Hide resolved

gregw commented Feb 1, 2024

View reviewed changes

...g-web/src/main/java/org/springframework/http/server/reactive/JettyCoreServerHttpRequest.java Outdated Show resolved Hide resolved

gregw commented Feb 1, 2024

View reviewed changes

...g-web/src/main/java/org/springframework/http/server/reactive/JettyCoreServerHttpRequest.java Outdated Show resolved Hide resolved

gregw mentioned this pull request Feb 1, 2024

ContentSourcePublisher throws from request jetty/jetty.project#11363

Closed

jhoeller added the in: web Issues in web modules (web, webmvc, webflux, websocket) label Feb 5, 2024

gregw and others added 14 commits February 6, 2024 10:25

Initial boiler plate implementation of JettyCore HttpHandler Adaptor

6ff974d

More implementation of the request side

db609a7

Created JettyCoreHttpServer

7a23fbf

Created JettyCoreHttpServer

418d699

WIP on tests

930d420

WIP on tests

eb38434

Cleanup start/stop for jetty

88e7467

retainable bytebuffer!

c5a327c

Non blocking invocation type

49abe72

split out into separate files

6ca453c

minor httpHeader optimizations

ea71c61

since updated with expected release

dd72a14

Initial implementation of the writeWith methods in JettyCoreServerHtt…

50e78d3

…pResponse Signed-off-by: Lachlan Roberts <lachlan@webtide.com>

Implement the ZeroCopyHttpOutputMessage interface for JettyCoreServer…

ab844d6

…HttpResponse Signed-off-by: Lachlan Roberts <lachlan@webtide.com>

lachlan-roberts and others added 14 commits June 6, 2024 10:38

Suppress NullAway warnings for Jetty WebSocket classes

fa5f800

Signed-off-by: Lachlan Roberts <lachlan.p.roberts@gmail.com>

fix other checkstyle warnings

442f11c

Signed-off-by: Lachlan Roberts <lachlan.p.roberts@gmail.com>

backed out abstract response change

bd25bd7

upgrade jetty

Steps towards abstract response class

3785321

checkstyle

d8eb3fa

updated response to use the abstract

c6b1914

updated response to use the abstract

a2420fc

add explicit dependency on jetty-websocket-api

5fbf83c

Signed-off-by: Lachlan Roberts <lachlan.p.roberts@gmail.com>

Polishing

9b7a2f4

Replace flatMap(...,1) with concatMap

b8d208d

Make copy of headers map

db82c22

Introduce JettyDataBuffer

16af65a

Polish JettyDataBuffer

6c48a83

Polishing

feef4a7

Polishing

d00ed1e

simonbasle reviewed Jun 6, 2024

View reviewed changes

lorban mentioned this pull request Jun 10, 2024

Experiment for aborting callbacks jetty/jetty.project#11876

Open

rstoyanchev reviewed Jun 11, 2024

View reviewed changes

poutsma modified the milestones: 6.2.0-M4, 6.2.0-M5 Jun 11, 2024

gregw added 3 commits June 12, 2024 10:50

Merge remote-tracking branch 'origin/main' into JettyCoreHttpHandlerA…

8753907

…dapter

addExact

260da30

doCommit not required

d415757

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Implement Eclipse Jetty core HTTP handler adapter #32097

Implement Eclipse Jetty core HTTP handler adapter #32097

gregw commented Jan 24, 2024

pivotal-cla commented Jan 24, 2024

gregw commented Jan 24, 2024

gregw commented Feb 1, 2024

gregw commented Feb 1, 2024

pivotal-cla commented Feb 1, 2024

gregw Feb 1, 2024

poutsma commented Jun 6, 2024

simonbasle Jun 6, 2024

simonbasle Jun 6, 2024 •

edited

simonbasle Jun 6, 2024

gregw Jun 12, 2024

simonbasle Jun 6, 2024

simonbasle Jun 6, 2024

gregw commented Jun 11, 2024

rstoyanchev left a comment •

edited

rstoyanchev Jun 10, 2024

gregw Jun 12, 2024

rstoyanchev Jun 10, 2024

gregw Jun 12, 2024

rstoyanchev Jun 10, 2024 •

edited

gregw Jun 12, 2024 •

edited

rstoyanchev Jun 11, 2024 •

edited

gregw Jun 11, 2024

gregw commented Jun 12, 2024

gregw commented Jun 12, 2024

gregw commented Jun 12, 2024

		// this.dataBuffer = dataBufferFactory.wrap(BufferUtil.copy(chunk.getByteBuffer())); // TODO this copy avoids multipart bugs
		this.dataBuffer = dataBufferFactory.wrap(chunk.getByteBuffer()); // TODO avoid double slice?

Implement Eclipse Jetty core HTTP handler adapter #32097

Are you sure you want to change the base?

Implement Eclipse Jetty core HTTP handler adapter #32097

Conversation

gregw commented Jan 24, 2024

pivotal-cla commented Jan 24, 2024

gregw commented Jan 24, 2024

gregw commented Feb 1, 2024

gregw commented Feb 1, 2024

pivotal-cla commented Feb 1, 2024

Choose a reason for hiding this comment

poutsma commented Jun 6, 2024

Choose a reason for hiding this comment

simonbasle Jun 6, 2024 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gregw commented Jun 11, 2024

rstoyanchev left a comment • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rstoyanchev Jun 10, 2024 • edited

Choose a reason for hiding this comment

gregw Jun 12, 2024 • edited

Choose a reason for hiding this comment

rstoyanchev Jun 11, 2024 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gregw commented Jun 12, 2024

gregw commented Jun 12, 2024

gregw commented Jun 12, 2024

simonbasle Jun 6, 2024 •

edited

rstoyanchev left a comment •

edited

rstoyanchev Jun 10, 2024 •

edited

gregw Jun 12, 2024 •

edited

rstoyanchev Jun 11, 2024 •

edited