[jira] [Commented] (QPID-7805) [Java Broker] [Websocket] Utilize jetty streaming API in implementation of wesocket transport support

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[jira] [Commented] (QPID-7805) [Java Broker] [Websocket] Utilize jetty streaming API in implementation of wesocket transport support

JIRA jira@apache.org

    [ 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: [hidden email]
For additional commands, e-mail: [hidden email]

Loading...