Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 333020 - SslSelectChannelConnector inconsistent with other connectors wrt largest web socket message receivable
Summary: SslSelectChannelConnector inconsistent with other connectors wrt largest web ...
Status: RESOLVED WONTFIX
Alias: None
Product: Jetty
Classification: RT
Component: server (show other bugs)
Version: 7.1.3   Edit
Hardware: PC Windows XP
: P3 minor (vote)
Target Milestone: 7.1.x   Edit
Assignee: Greg Wilkins CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-12-21 09:49 EST by Jeremy Stone CLA
Modified: 2011-09-06 01:05 EDT (History)
2 users (show)

See Also:

Attachments
Test cases (6.66 KB, application/zip)
2010-12-21 09:51 EST, Jeremy Stone CLA 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Jeremy Stone CLA 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 CLA 2010-12-21 09:51:38 EST 
Created attachment 185636 [details]
Test cases
Comment 2 Jeremy Stone CLA 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 CLA 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 CLA 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).