Skip to content
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

Mono from sendWebSocket completes at the end of the session #393

Closed
rstoyanchev opened this issue Jul 19, 2018 · 3 comments
Closed

Mono from sendWebSocket completes at the end of the session #393

rstoyanchev opened this issue Jul 19, 2018 · 3 comments
Labels
type/bug A general bug

Comments

@rstoyanchev
Copy link
Contributor

Not sure 100% if this is an issue or expected behavior but according to the Javadoc for HttpServerResponse#sendWebSocket it returns "a Mono completing when upgrade is confirmed". Instead the Mono seems to complete only after WebSocket session handling completes.

This comes through an issue reported against Spring Session and then the Spring Framework https://jira.spring.io/browse/SPR-17051 where a WebSocket handshake request completes at the end of the WebSocket connection (i.e. much later) and saves an already invalidated WebSession causing havoc.

@violetagg violetagg added this to the 0.7.x Maintenance Backlog milestone Jul 19, 2018
@smaldini smaldini added type/bug A general bug type/documentation A documentation update and removed type/bug A general bug labels Jul 21, 2018
@smaldini
Copy link
Contributor

smaldini commented Jul 21, 2018

It is actually implemented as such so the javadoc is wrong. Was wondering if it would make sense otherwise tho. Right now it allows to back propagate the inner callback error/complete outside the callback :

return FutureMono.from(ops.handshakerResult)
				                 .then(Mono.defer(() -> {
					                 //skip handler if no matching subprotocol
					                 if (protocols != null && ops.selectedSubprotocol() == null) {
						                 return Mono.empty();
					                 }
					                 return Mono.fromDirect(websocketHandler.apply(ops, ops));
				                 }))
				                 .doAfterSuccessOrError(ops);

Not that it is important to return something in the outer handler since close will be handled in doAfterSuccessOrError, let us know if you want this behavior to change (so the "then" in the code above becomes a side effect.

@rstoyanchev
Copy link
Contributor Author

I would prefer if it worked as Javadoc says.

The handshake/upgrade is associated with an HttpHandler (or a BiFunction<HttpServerRequest, HttpServerResponse, Mono<Void>> in Reactor Netty) while the the WebSocket session is associated with a WebSocketHandler (or a BiFunction<? super WebsocketInbound, ? super WebsocketOutbound, ? extends Publisher<Void>> in Reactor Netty).

The two have different lifecycles and duration (short vs potentially very long) and different potential outcomes (e.g. successful upgrade but error in websocket session). Combining the two like that leads to strange results like attempting to save an already invalidated WebSession (because user logged out in another tab) because the WebFilter chain was held up for the entire duration of the WebSocket session.

@smaldini smaldini added type/bug A general bug and removed type/documentation A documentation update labels Aug 14, 2018
@yu199195
Copy link

ues spring webflux websocket ,Just one big request ,AbstractChannelHandlerContext CPU 100%

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type/bug A general bug
Projects
None yet
Development

No branches or pull requests

4 participants