Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 333020

Summary:

SslSelectChannelConnector inconsistent with other connectors wrt largest web socket message receivable

Product:

[RT] Jetty

Reporter:

Jeremy Stone <jeremy.stone>

Component:

server

Assignee:

Greg Wilkins <gregw>

Status:

RESOLVED WONTFIX

QA Contact:

Severity:

minor

Priority:

CC:

jeremy.stone, jetty-inbox

Version:

7.1.3

Target Milestone:

7.1.x

Hardware:

OS:

Windows XP

Whiteboard:

Attachments:

Description	Flags
Test cases	none

Description Jeremy Stone

2010-12-21 09:49:02 EST

Build Identifier: 7.1.6.v20100715 also with 7.2.2.v20101205

If Jetty is configured with a SocketConnector, an SslSocketConnector or an SelectChannelConnector the maximum number of bytes that a WebSocket can receive as a single message is by default 8192 (including frame type, message length prefix or sentinel byte).

Clients with this knowledge can therefore fragment web socket messages accordingly. However with SslSelectChannelConnector get the following stack trace when send message of total size 8192 bytes:

java.lang.IllegalStateException: Status = BUFFER_OVERFLOW HandshakeStatus = NOT_HANDSHAKING|bytesConsumed = 0 bytesProduced = 0 0 8192
	at org.eclipse.jetty.io.nio.SslSelectChannelEndPoint.unwrap(SslSelectChannelEndPoint.java:726)
	at org.eclipse.jetty.io.nio.SslSelectChannelEndPoint.fill(SslSelectChannelEndPoint.java:323)
	at org.eclipse.jetty.websocket.WebSocketParserD00.parseNext(WebSocketParserD00.java:107)
	at org.eclipse.jetty.websocket.WebSocketConnectionD00.handle(WebSocketConnectionD00.java:159)
	at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:508)
	at org.eclipse.jetty.io.nio.SelectChannelEndPoint.access$000(SelectChannelEndPoint.java:34)
	at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:40)
	at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:451)
	at java.lang.Thread.run(Unknown Source)

Reproducible: Always

Steps to Reproduce:
Run test cases (one for each connector type) supplied as attachment.

Comment 1 Jeremy Stone

2010-12-21 09:51:38 EST

Created attachment 185636 [details]
Test cases

Comment 2 Jeremy Stone

2010-12-22 09:29:38 EST

A work around may be to use a WebSocketFactory with a larger buffer size.

Comment 3 Greg Wilkins

2011-01-10 17:29:54 EST

I will probably defer this for a few weeks until the current round of websocket spec changes are resolved.

Comment 4 Greg Wilkins

2011-09-06 01:05:27 EDT

This should no longer be an issue as the read buffer size is now unrelated to the max message size.

messages larger than the read buffer are delivered to the frame handler as fragments and reassembled according to the maxMessageSize set on the connection (which is the same for all connector types).