-
Notifications
You must be signed in to change notification settings - Fork 654
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
WebSocket aggregation FrameTooLargeException handling doesn't close connection #3295
Comments
@joebyneil I tried to reproduce this behaviour but without success - see #3298 Also this log |
Thanks for the example! I'll play around with this more tomorrow and see if I can reproduce without RSocket also in the picture. I've added some debug logs below in case they show anything obvious, but does seem that the server is still reading and writing from the connection after getting the error. The main observation is that HttpServer is still reading, but each time just produces another log to say that it already got
|
I'll close for now. I can see the FrameTooLargeException being passed through to RSocket, so seems like everything on reactor-netty side is working as expected. I'll keep looking and raise anything I find on the rsocket-java side. Thanks for taking a look at this, it has been really helpful and I appreciate you taking the time. |
Hey 👋
Expected Behavior
We receive the following exception caused by MessageAggregator when aggregating frames.
FluxReceive : [dfd30519-1, L:/[0:0:0:0:0:0:0:1]:8083 - R:/[0:0:0:0:0:0:0:1]:54580] An exception has been observed post termination, use DEBUG level to see the full stack: io.netty.handler.codec.TooLongFrameException: content length exceeded 5000000 bytes is received
.Expecting that that this situation would cause a close frame to be sent and the websocket is disposed. I expected this behaviour because this is what would happen if a single frame was oversized for the
.maxFramePayloadLength(maxFramePayloadLength)
.Where Netty throws this
Actual Behavior
The WebSocket remains open, but the frames have been dropped leading to application level failure. (RSocket in my case)
Steps to Reproduce
I'm struggling to make a reproducer for this because it's dealing with aggregated frames. But keen to see if you have any thoughts here, or if this is something we may just have to handle at the application level.
We have been able to reproduce with some internal testing pages.
We configure max payload limits both on both aggregateFrames and WebSocketServerSpec. Compression is explicitly disabled.
With both configured, sending large messages doesn't cause the WebSocket connection to close.
The error eventually shows in our logs, and by that point the connection has been killed due to application level keep alives being missed. (~60 seconds later)
Possible Solution
Wondering if the exception from MessageAggregator needs to be explicitly handled somewhere, or if I'm incorrect in expecting this to cause a websocket close and instead we should look to handle this at application level.
Your Environment
reactor-netty: 1.1.17
java -version
):openjdk version "17.0.6" 2023-01-17 LTS
uname -a
):Darwin Joebys-Laptop 23.4.0 Darwin Kernel Version 23.4.0: Fri Mar 15 00:10:42 PDT 2024; root:xnu-10063.101.17~1/RELEASE_ARM64_T6000 arm64
The text was updated successfully, but these errors were encountered: