users@websocket-spec.java.net

[jsr356-users] [jsr356-experts] Re: Re: Re: Buffer sizes

From: Mark Thomas <mark_at_homeinbox.net>
Date: Fri, 01 Feb 2013 11:12:57 +0000

On 01/02/2013 00:58, Danny Coward wrote:
> Let me see if I can add a useful summary:-
>
> - on frame vs API partial messages
>
> We didn't ever intend the API to dictate anything about the underlying
> frames used to get or send the messages (I think we all agree on that).
> It looks like the RFC uses 'fragment' to describes messages split across
> multiple frames. I checked our javadoc uses 'partial messages'. I'm
> happy to put something clear in a class comment to really stress the
> developer should not think they are related. OK ?

The Javadoc does not use "partial message" consistently.

MessageHandler.Async<T> uses "fragment" in some places as does
RemoteEndpoint.

I think all of those instances of "fragment" need to be changed to
"partial message".


> - on buffer sizes
>
> I think we originally intended the maximum limits to apply to incoming
> messages, mainly because some of the developer APIs force buffering
> (like onMessage(String s)) and the developer needs to say how big an
> incoming message is too big to wait around for. I think that remains an
> important control. I agree the javadocs are not clear.
>
> The WebSocketContainer holds container scope default maximums, they can
> be overridden on a per connection basis the corresponding Session instance.

The session only has a single limit. The container has separate limits
for Text and Binary. That needs to be consistent.

> So does that leave us trying to decide whether to add controls on the
> buffer size for outgoing messages ? Why would the developer want to
> limit or control that ?

If batching is being used I can imagine a circumstance where the
application would wish to control the size of the outgoing buffer.

In non-batching mode it is less clear. I suspect folks that are trying
to fine tune performance may want to be able to modify the size of the
outgoing buffer.

Mark

> - int/long
>
> No-one seems to think that trying to create a buffer bigger than
> Integer.MAX_VALUE is ever going to make sense, so I am fine turning that
> into an int.
>
> - Danny