[
https://issues.apache.org/jira/browse/QPID-7805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16047991#comment-16047991
]
Keith Wall commented on QPID-7805:
----------------------------------
I don't think this is suitable for AMQP web socket use. Jetty's streaming API
dispatches requests to the @OnWebSocketMessage/InputStream annotated method in
request arrival order, but does not await the completion of the first request
before dispatching the second. In other words, the requests race. I was
seeing
org.apache.qpid.tests.protocol.v1_0.extensions.websocket.WebSocketTest#amqpFramesSplitOverManyWebSocketFrames
fail sporadically when I switch WebSocketProvider to use an InputStream, I
couldn't find an authoritative source, but did find this posting:
https://dev.eclipse.org/mhonarc/lists/jetty-users/msg05960.html
> [Java Broker] [Websocket] Utilize jetty streaming API in implementation of
> wesocket transport support
> -----------------------------------------------------------------------------------------------------
>
> Key: QPID-7805
> URL: https://issues.apache.org/jira/browse/QPID-7805
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
> Reporter: Alex Rudyy
> Attachments: 0001-QPID-7805-WIP.patch
>
>
> On upgrading jetty to 9.4.x, the reflection was used to set maximum binary
> message size to 0 (unconstrained). The improved github request [1] was raised
> with jetty to relax WebSocketPolicy.setMax*MessageSize to allow setting of
> "maximum binary message size" to 0.
> The github request was implemented but it was suggested to use streaming API
> instead. Here is the quotes form the reply:
> {quote}
> joakime:
> Setting the {{maxBinaryMessageSize}} at {{0}} would mean you never send a
> binary message payload (no length).
> Jetty has traditionally not support unconstrained whole binary messages
> delivery.
> It only supports unconstrained binary messages via the streaming APIs.
> Internally, the maximum whole message size (or individual frame payload size)
> is {{Integer.MAX_VALUE}}.
> This is well below what the WebSocket protocol is capable of handling at the
> frame level.
> But if you are attempting to set this for the frame level, know that efforts
> underway with WebSocket over HTTP2 will likely make the websocket frame
> maximum conform to the HTTP2 frame maximum (65k IIRC)
> Also, with websocket extensions in play, the frame level maximums can also be
> constrained to small values.
> Know that there are 2 values when using the Jetty Native WebSocket API
> (message and buffer), but only 1 value when using JSR356 WebSocket API
> (buffer).
> I'll relax the message size limit checks, but not the buffer size limits.
> Know that you are opening yourself to many different classes of OutOfMemory
> errors if you do this.
> It would be trivially easy for a websocket client to crash your server with a
> single short message with this kind of configuration.
> {quote}
> {quote}
> Change applied.
> But I would encourage you to either use the streaming APIs or set the max
> message size to something reasonable.
> {quote}
> Some of the Streaming API examples are provided at [2]
> [1] https://github.com/eclipse/jetty.project/issues/1569
> [2] https://webtide.com/jetty-9-updated-websocket-api/
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
