-
Notifications
You must be signed in to change notification settings - Fork 646
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
Comments
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. |
I would prefer if it worked as Javadoc says. The handshake/upgrade is associated with an 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 |
ues spring webflux websocket ,Just one big request ,AbstractChannelHandlerContext CPU 100% |
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.
The text was updated successfully, but these errors were encountered: