qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Rudyy (JIRA)" <j...@apache.org>
Subject [jira] [Created] (QPID-7805) [Java Broker] [Websocket] Utilize jetty streaming API in implementation of wesocket transport support
Date Thu, 01 Jun 2017 10:03:04 GMT
Alex Rudyy created QPID-7805:

             Summary: [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

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 hubrequest was implemented but it was suggested to use streaming API instead. Here is
the quotes form the reply:

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.

Change applied.

But I would encourage you to either use the streaming APIs or set the max message size to
something reasonable.

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

To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org

View raw message