On 2/11/13 10:02 AM, Joakim Erdfelt wrote:
> Looks like Session.getMaxMessageSize() has been removed in favor of ..
>
> Session.getMaxBinaryMessageBufferSize()
> Session.getMaxTextMessageBufferSize()
Yes, to make it consistent with the application-wide defaults set on the
WebSocketContainer.
>
> Is is expected that if messages arrive exceeding those buffer sizes
> the implementation fails the websocket and reports the error to the
> websocket?
> I would think a close reason of CloseCode.TOO_BIG (1009) and indicate
> that to the client.
>
> Is this the behavior now?
I think that would be a reasonable approach, but it might not be the
only reasonable approach: I'm not sure if we should always require the
connection to be closed because of one message that is too big. Perhaps
we should also allow implementations to report the error to the
receiving endpoint, but not close the connection if they want to ?
Let's see what the eg thinks, I've logged an issue for this.
- Danny
>
> --
> Joakim Erdfelt <joakim_at_intalio.com <mailto:joakim_at_intalio.com>>
> webtide.com <http://www.webtide.com/>
> Developer advice, services and support
> from the Jetty & CometD experts
> eclipse.org/jetty <http://eclipse.org/jetty/> - cometd.org
> <http://cometd.org/>
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation