Spring/spring-framework
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Add WebSocket transport configuration support

Browse Source 
Issue: SPR-11527
This commit is contained in:
Rossen Stoyanchev
2014-03-24 18:05:37 -04:00
parent 1e9960e1ce
commit c11484b2e7
14 changed files with 184 additions and 100 deletions
Download Patch File Download Diff File Expand all files Collapse all files

112
spring-websocket/src/main/resources/org/springframework/web/socket/config/spring-websocket-4.0.xsd
View File

@@ -457,17 +457,114 @@
<xsd:annotation>
<xsd:documentation><![CDATA[
Configures broker-backed messaging over WebSocket using a higher-level messaging sub-protocol.
Registers a SimpleUrlHandlerMapping and maps
paths to registered Controllers.
Registers a SimpleUrlHandlerMapping and maps paths to registered Controllers.
A StompSubProtocolHandler is registered
to handle various versions of the STOMP protocol.
A StompSubProtocolHandler is registered to handle various versions of the STOMP protocol.
See EnableWebSocketMessageBroker javadoc for information on code-based alternatives to enabling broker-backed messaging.
]]></xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element name="transport" minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation><![CDATA[
Configure options related to the processing of messages received from and sent to WebSocket clients.
]]></xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:attribute name="message-size" type="xsd:string">
<xsd:annotation>
<xsd:documentation><![CDATA[
Configure the maximum size for an incoming sub-protocol message.
For example a STOMP message may be received as multiple WebSocket messages
or multiple HTTP POST requests when SockJS fallback options are in use.
In theory a WebSocket message can be almost unlimited in size.
In practice WebSocket servers impose limits on incoming message size.
STOMP clients for example tend to split large messages around 16K
boundaries. Therefore a server must be able to buffer partial content
and decode when enough data is received. Use this property to configure
the max size of the buffer to use.
The default value is 64K (i.e. 64 * 1024).
NOTE that the current version 1.2 of the STOMP spec
does not specifically discuss how to send STOMP messages over WebSocket.
Version 2 of the spec will but in the mean time existing client libraries
have already established a practice that servers must handle.
]]></xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="send-timeout" type="xsd:string">
<xsd:annotation>
<xsd:documentation><![CDATA[
Configure a time limit (in milliseconds) for the maximum amount of a time
allowed when sending messages to a WebSocket session or writing to an
HTTP response when SockJS fallback option are in use.
In general WebSocket servers expect that messages to a single WebSocket
session are sent from a single thread at a time. This is automatically
guaranteed when using {@code @EnableWebSocketMessageBroker} configuration.
If message sending is slow, or at least slower than rate of messages sending,
subsequent messages are buffered until either the {@code sendTimeLimit}
or the {@code sendBufferSizeLimit} are reached at which point the session
state is cleared and an attempt is made to close the session.
NOTE that the session time limit is checked only
on attempts to send additional messages. So if only a single message is
sent and it hangs, the session will not time out until another message is
sent or the underlying physical socket times out. So this is not a
replacement for WebSocket server or HTTP connection timeout but is rather
intended to control the extent of buffering of unsent messages.
NOTE that closing the session may not succeed in
actually closing the physical socket and may also hang. This is true
especially when using blocking IO such as the BIO connector in Tomcat
that is used by default on Tomcat 7. Therefore it is recommended to ensure
the server is using non-blocking IO such as Tomcat's NIO connector that
is used by default on Tomcat 8. If you must use blocking IO consider
customizing OS-level TCP settings, for example
{@code /proc/sys/net/ipv4/tcp_retries2} on Linux.
The default value is 10 seconds (i.e. 10 * 10000).
]]></xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="send-buffer-size" type="xsd:string">
<xsd:annotation>
<xsd:documentation><![CDATA[
Configure the maximum amount of data to buffer when sending messages
to a WebSocket session, or an HTTP response when SockJS fallback
option are in use.
In general WebSocket servers expect that messages to a single WebSocket
session are sent from a single thread at a time. This is automatically
guaranteed when using {@code @EnableWebSocketMessageBroker} configuration.
If message sending is slow, or at least slower than rate of messages sending,
subsequent messages are buffered until either the {@code sendTimeLimit}
or the {@code sendBufferSizeLimit} are reached at which point the session
state is cleared and an attempt is made to close the session.
NOTE that closing the session may not succeed in
actually closing the physical socket and may also hang. This is true
especially when using blocking IO such as the BIO connector in Tomcat
configured by default on Tomcat 7. Therefore it is recommended to ensure
the server is using non-blocking IO such as Tomcat's NIO connector used
by default on Tomcat 8. If you must use blocking IO consider customizing
OS-level TCP settings, for example {@code /proc/sys/net/ipv4/tcp_retries2}
on Linux.
The default value is 512K (i.e. 512 * 1024).
@param sendBufferSizeLimit the maximum number of bytes to buffer when
sending messages; if the value is less than or equal to 0 then buffering
is effectively disabled.
]]></xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:complexType>
</xsd:element>
<xsd:element name="stomp-endpoint" minOccurs="1" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation><![CDATA[
@@ -575,13 +672,6 @@
]]></xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="message-buffer-size" type="xsd:int">
<xsd:annotation>
<xsd:documentation><![CDATA[
The message buffer size limit in bytes for simple messaging protocols like STOMP.
]]></xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="order" type="xsd:token">
<xsd:annotation>
<xsd:documentation><![CDATA[