I don't think the protocol has any means of feedback except for the close,
though. I think it's perfectly fine, and safest, to close to connection in
that case.
On Mon, Feb 11, 2013 at 7:34 PM, Danny Coward <danny.coward_at_oracle.com>wrote:
> 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>
> webtide.com <http://www.webtide.com/>
> Developer advice, services and support
> from the Jetty & CometD experts
> eclipse.org/jetty - cometd.org
>
>
>
> --
> <http://www.oracle.com> * Danny Coward *
> Java EE
> Oracle Corporation
>
--
You can find me on the net at:
http://antwerkz.com http://antwerkz.com/+
http://antwerkz.com/twitter http://antwerkz.com/github