maxFramePayloadLength seems to be hardcoded when using WebSocketClient

[vsrakesh]

Describe the bug

We are occasionally hitting an exception (shown below) caused due to the payload in a websocket frame being larger than 1280000 bytes while trying to read log messages from a websocket.
Had tried the instructions on setting max-frame-size described in #7172 without much luck.

Looks like io.undertow.websockets.jsr.WebsocketConnectionBuilder has this value hardcoded as 1280000.

2021-05-13 18:41:24,350 WARN [io.net.cha.DefaultChannelPipeline] (nioEventLoopGroup-2-3) An exceptionCaught() event was fired, and it reached at the tail of the pipeline. It usually means the last handler in the pipeline did not handle the exception.: io.netty.handler.codec.http.websocketx.CorruptedWebSocketFrameException: Max frame length of 1280000 has been exceeded.
at io.netty.handler.codec.http.websocketx.WebSocket08FrameDecoder.protocolViolation(WebSocket08FrameDecoder.java:426)
at io.netty.handler.codec.http.websocketx.WebSocket08FrameDecoder.decode(WebSocket08FrameDecoder.java:286)
at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:501)
at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:440)
at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:163)
at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:714)
at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:650)
at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:576)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493)
at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:834)

Expected behavior

The maxFramePayloadLength setting should ideally be configurable. Any workaround would be much appreciated.

Actual behavior

This setting/value is hardcoded

To Reproduce

A client connecting to a websocket that sends frames with payload larger than 1280000 bytes

Steps to reproduce the behavior:
A client connecting to a websocket that sends frames with payload larger than 1280000 bytes

Configuration

No Specific properties required to reproduce this issue

Screenshots

Environment (please complete the following information):

Output of uname -a or ver

Output of java -version

GraalVM version (if different from Java)

Quarkus version or git rev

Build tool (ie. output of mvnw --version or gradlew --version)

Additional context

(Add any other context about the problem here.)

[pabulo-silva-tdx]

Hi Guys I hit this same issue on version 1.13.6.Final and after doing some debugging I think I found the culprit:

io.quarkus.undertow.websockets.runtime.WebsocketRecorder#createHandler

where WebSocketDeploymentInfo get max frame size is not taking into account when creating VertxServerWebSocketContainer and also not managed in io.undertow.websockets.vertx.VertxWebSocketHandler#VertxWebSocketHandler. So in the end we get the default value.

my previous version before we upgrade to this one was 1.10.3.Final and it worked correctly but the code is too different so I can't track where we should put this change to provide a PR but my guessing it would be on VertxWebSocketHandler do something like your are doing for server extensions.

[gsmet]

Good detective work. Can you check if #17605 fixes it for you?

https://github.com/quarkusio/quarkus/blob/main/CONTRIBUTING.md#checking-an-issue-is-fixed-in-main will probably be useful except you need to test my branch instead of main.

Thanks!

[pabulo-silva-tdx]

Seems great, thx :)