Polish reference manual regarding WebSocket
- fixed typos - improved grammar and punctuation - fixed class names
This commit is contained in:
Sam Brannen
parent
81ae1153e6
commit
c7a456c0bf
|
|
@ -1201,7 +1201,7 @@ method has been added.
|
|||
=== WebSocket STOMP Messaging Improvements
|
||||
|
||||
* SockJS (Java) client-side support. See `SockJsClient` and classes in same package.
|
||||
* New application context events `SessionSubscribeEvent` and `SessionUnubscribeEvent` published
|
||||
* New application context events `SessionSubscribeEvent` and `SessionUnsubscribeEvent` published
|
||||
when STOMP clients subscribe and unsubscribe.
|
||||
* New "websocket" scope. See <<websocket-stomp-websocket-scope>>.
|
||||
* `@SendToUser` can target only a single session and does not require an authenticated user.
|
||||
|
|
@ -1213,8 +1213,8 @@ method has been added.
|
|||
* Optimized message creation including support for temporary message mutability
|
||||
and avoiding automatic message id and timestamp creation. See Javadoc of
|
||||
`MessageHeaderAccessor`.
|
||||
* STOMP/WebSocket connections that have not activity 60 seconds after the WebSocket
|
||||
session is established. See https://jira.spring.io/browse/SPR-11884[SPR-11884].
|
||||
* Close STOMP/WebSocket connections that have no activity within 60 seconds after the
|
||||
WebSocket session is established. See https://jira.spring.io/browse/SPR-11884[SPR-11884].
|
||||
|
||||
=== Testing Improvements
|
||||
|
||||
|
|
@ -38947,9 +38947,9 @@ application level WebSocket sub-protocol.
|
|||
WebSocket, covering adoption challenges, design considerations, and thoughts on
|
||||
when it is a good fit.
|
||||
|
||||
<<websocket-server>> reviews the Spring WebSocket API on the
|
||||
server-side while <<websocket-fallback>> explains the SockJS protocol and shows
|
||||
how to configure and use it.
|
||||
<<websocket-server>> reviews the Spring WebSocket API on the server-side, while
|
||||
<<websocket-fallback>> explains the SockJS protocol and shows how to configure
|
||||
and use it.
|
||||
|
||||
<<websocket-stomp-overview>> introduces the STOMP messaging protocol.
|
||||
<<websocket-stomp-enable>> demonstrates how to configure STOMP support in Spring.
|
||||
|
|
@ -38966,10 +38966,10 @@ applications.
|
|||
The WebSocket protocol http://tools.ietf.org/html/rfc6455[RFC 6455] defines an important
|
||||
new capability for web applications: full-duplex, two-way communication between client
|
||||
and server. It is an exciting new capability on the heels of a long history of
|
||||
techniques to make the web more interactive including Java applets, XMLHttpRequest,
|
||||
techniques to make the web more interactive including Java Applets, XMLHttpRequest,
|
||||
Adobe Flash, ActiveXObject, various Comet techniques, server-sent events, and others.
|
||||
|
||||
A proper introduction of the WebSocket protocol is beyond the scope of this
|
||||
A proper introduction to the WebSocket protocol is beyond the scope of this
|
||||
document. At a minimum however it's important to understand that HTTP is used only for
|
||||
the initial handshake, which relies on a mechanism built into HTTP to request
|
||||
a protocol upgrade (or in this case a protocol switch) to which the server can respond with
|
||||
|
|
@ -38989,20 +38989,17 @@ and also provides additional value-add as explained in the rest of the introduct
|
|||
An important challenge to adoption is the lack of support for WebSocket in some
|
||||
browsers. Notably the first Internet Explorer version to support WebSocket is
|
||||
version 10 (see http://caniuse.com/websockets for support by browser versions).
|
||||
Furthermore, some restrictive proxies
|
||||
may be configured in ways that either preclude the attempt to do HTTP upgrade
|
||||
or otherwise break connection after some time because it has remained opened
|
||||
for too long. A good overview on this topic from Peter Lubbers is available in
|
||||
the InfoQ article
|
||||
Furthermore, some restrictive proxies may be configured in ways that either
|
||||
preclude the attempt to do an HTTP upgrade or otherwise break connection after
|
||||
some time because it has remained opened for too long. A good overview on this
|
||||
topic from Peter Lubbers is available in the InfoQ article
|
||||
http://www.infoq.com/articles/Web-Sockets-Proxy-Servers["How HTML5 Web Sockets Interact With Proxy Servers"].
|
||||
|
||||
|
||||
Therefore to build a WebSocket application today, fallback options are required
|
||||
to simulate the WebSocket API where necessary.
|
||||
Spring Framework provides such transparent fallback
|
||||
options based on the https://github.com/sockjs/sockjs-protocol[SockJS protocol].
|
||||
These options can be enabled through configuration and do not require
|
||||
modifying the application otherwise.
|
||||
Therefore to build a WebSocket application today, fallback options are required in
|
||||
order to simulate the WebSocket API where necessary. The Spring Framework provides
|
||||
such transparent fallback options based on the https://github.com/sockjs/sockjs-protocol[SockJS protocol].
|
||||
These options can be enabled through configuration and do not require modifying the
|
||||
application otherwise.
|
||||
|
||||
|
||||
|
||||
|
|
@ -39026,7 +39023,7 @@ to traditional messaging applications (e.g. JMS, AMQP).
|
|||
Spring Framework 4 includes a new `spring-messaging` module with key
|
||||
abstractions from the
|
||||
http://projects.spring.io/spring-integration/[Spring Integration] project
|
||||
such as `Message`, `MessageChannel`, `MessageHandler` and others that can serve as
|
||||
such as `Message`, `MessageChannel`, `MessageHandler`, and others that can serve as
|
||||
a foundation for such a messaging architecture. The module also includes a
|
||||
set of annotations for mapping messages to methods, similar to the Spring MVC
|
||||
annotation based programming model.
|
||||
|
|
@ -39051,14 +39048,14 @@ Servlet API alone.
|
|||
|
||||
For this reason the WebSocket RFC defines the use of
|
||||
http://tools.ietf.org/html/rfc6455#section-1.9[sub-protocols].
|
||||
During the handshake, client and server can use the header
|
||||
During the handshake, the client and server can use the header
|
||||
`Sec-WebSocket-Protocol` to agree on a sub-protocol, i.e. a higher, application-level
|
||||
protocol to use. The use of a sub-protocol is not required, but
|
||||
even if not used, applications will still need to choose a message
|
||||
format that both client and server can understand. That format can be custom,
|
||||
format that both the client and server can understand. That format can be custom,
|
||||
framework-specific, or a standard messaging protocol.
|
||||
|
||||
Spring Framework provides support for using
|
||||
The Spring Framework provides support for using
|
||||
http://stomp.github.io/stomp-specification-1.2.html#Abstract[STOMP] -- a simple, messaging protocol
|
||||
originally created for use in scripting languages with frames inspired
|
||||
by HTTP. STOMP is widely supported and well suited for use over
|
||||
|
|
@ -39069,17 +39066,17 @@ WebSocket and over the web.
|
|||
[[websocket-intro-when-to-use]]
|
||||
==== Should I Use WebSocket?
|
||||
With all the design considerations surrounding the use of WebSocket, it is
|
||||
reasonable to ask when is it appropriate to use?
|
||||
reasonable to ask, "When is it appropriate to use?".
|
||||
|
||||
The best fit for WebSocket is in web applications where client and
|
||||
server need to exchange events at high frequency and at low latency. Prime
|
||||
candidates include but are not limited to applications in finance, games,
|
||||
The best fit for WebSocket is in web applications where the client and
|
||||
server need to exchange events at high frequency and with low latency. Prime
|
||||
candidates include, but are not limited to, applications in finance, games,
|
||||
collaboration, and others. Such applications are both very sensitive to time
|
||||
delays and also need to exchange a wide variety of messages at high
|
||||
delays and also need to exchange a wide variety of messages at a high
|
||||
frequency.
|
||||
|
||||
For other application types, however, this may not be the case.
|
||||
For example, a news or social feed that shows breaking news as they become
|
||||
For example, a news or social feed that shows breaking news as it becomes
|
||||
available may be perfectly okay with simple polling once every few minutes.
|
||||
Here latency is important, but it is acceptable if the news takes a
|
||||
few minutes to appear.
|
||||
|
|
@ -39088,19 +39085,19 @@ Even in cases where latency is crucial, if the volume of messages is
|
|||
relatively low (e.g. monitoring network failures) the use of
|
||||
https://spring.io/blog/2012/05/08/spring-mvc-3-2-preview-techniques-for-real-time-updates[long polling]
|
||||
should be considered as a relatively simple alternative that
|
||||
works reliably and is comparable by efficiency (again assuming the volume of
|
||||
works reliably and is comparable in terms of efficiency (again assuming the volume of
|
||||
messages is relatively low).
|
||||
|
||||
It is the combination of both low latency and high frequency of messages that can make
|
||||
the use of the WebSocket protocol critical. Even in such applications,
|
||||
the choice remains whether all client-server
|
||||
communication should be done through WebSocket messages as opposed to using
|
||||
HTTP and REST? The answer is going to vary by application, however, it is likely
|
||||
HTTP and REST. The answer is going to vary by application; however, it is likely
|
||||
that some functionality may be exposed over both WebSocket and as a REST API in
|
||||
order to provide clients with alternatives. Furthermore, a REST API call may need
|
||||
to broadcast a message to interested clients connected via WebSocket.
|
||||
|
||||
Spring Framework allows `@Controller` and `@RestController` classes to have both
|
||||
The Spring Framework allows `@Controller` and `@RestController` classes to have both
|
||||
HTTP request handling and WebSocket message handling methods.
|
||||
Furthermore, a Spring MVC request handling method, or any application
|
||||
method for that matter, can easily broadcast a message to all interested
|
||||
|
|
@ -39155,7 +39152,7 @@ likely extending either `TextWebSocketHandler` or `BinaryWebSocketHandler`:
|
|||
----
|
||||
|
||||
There is dedicated WebSocket Java-config and XML namespace support for mapping the above
|
||||
WebSocket handler at a specific URL:
|
||||
WebSocket handler to a specific URL:
|
||||
|
||||
[source,java,indent=0]
|
||||
[subs="verbatim,quotes"]
|
||||
|
|
@ -39295,7 +39292,7 @@ understand. However, special considerations apply with regards to JSR-356 runtim
|
|||
The Java WebSocket API (JSR-356) provides two deployment mechanisms. The first
|
||||
involves a Servlet container classpath scan (Servlet 3 feature) at startup; and
|
||||
the other is a registration API to use at Servlet container initialization.
|
||||
Neither of these mechanism make it possible to use a single "front controller"
|
||||
Neither of these mechanism makes it possible to use a single "front controller"
|
||||
for all HTTP processing -- including WebSocket handshake and all other HTTP
|
||||
requests -- such as Spring MVC's `DispatcherServlet`.
|
||||
|
||||
|
|
@ -39314,12 +39311,12 @@ will follow their example regardless of when it is addressed in the
|
|||
Java WebSocket API.
|
||||
====
|
||||
|
||||
A secondary consideration is that Servlet containers with JSR-356 support
|
||||
are expected to perform an SCI scan that can slow down application startup,
|
||||
in some cases dramatically. If a significant impact is observed after an
|
||||
A secondary consideration is that Servlet containers with JSR-356 support are expected
|
||||
to perform a `ServletContainerInitializer` (SCI) scan that can slow down application
|
||||
startup, in some cases dramatically. If a significant impact is observed after an
|
||||
upgrade to a Servlet container version with JSR-356 support, it should
|
||||
be possible to selectively enable or disable web fragments (and SCI scanning)
|
||||
through the use of an `<absolute-ordering />` element in `web.xml`:
|
||||
through the use of the `<absolute-ordering />` element in `web.xml`:
|
||||
|
||||
[source,xml,indent=0]
|
||||
[subs="verbatim,quotes,attributes"]
|
||||
|
|
@ -39364,7 +39361,7 @@ Each underlying WebSocket engine exposes configuration properties that control
|
|||
runtime characteristics such as the size of message buffer sizes, idle timeout,
|
||||
and others.
|
||||
|
||||
For Tomcat, WildFly, and Glassfish add a `ServletServerContainerFactoryBean` to your
|
||||
For Tomcat, WildFly, and GlassFish add a `ServletServerContainerFactoryBean` to your
|
||||
WebSocket Java config:
|
||||
|
||||
[source,java,indent=0]
|
||||
|
|
@ -39486,10 +39483,10 @@ or WebSocket XML namespace:
|
|||
[[websocket-server-allowed-origins]]
|
||||
==== Configuring allowed origins
|
||||
|
||||
As of Spring Framework 4.1.5, Websocket and SockJS default behavior is to accept only same
|
||||
origin requests. It is also possible to allow all or a specified list of origins.
|
||||
As of Spring Framework 4.1.5, the default behavior for WebSocket and SockJS is to accept
|
||||
only _same origin_ requests. It is also possible to allow _all_ or a specified list of origins.
|
||||
This check is mostly designed for browser clients. There is nothing preventing other types
|
||||
of client to modify the `Origin` header value (see
|
||||
of clients from modifying the `Origin` header value (see
|
||||
https://tools.ietf.org/html/rfc6454[RFC 6454: The Web Origin Concept] for more details).
|
||||
|
||||
The 3 possible behaviors are:
|
||||
|
|
@ -39498,14 +39495,14 @@ The 3 possible behaviors are:
|
|||
Iframe HTTP response header `X-Frame-Options` is set to `SAMEORIGIN`, and JSONP
|
||||
transport is disabled since it does not allow to check the origin of a request.
|
||||
As a consequence, IE6 and IE7 are not supported when this mode is enabled.
|
||||
* Allow a specified list of origins: each provided allowed origin must start by `http://`
|
||||
* Allow a specified list of origins: each provided _allowed origin_ must start with `http://`
|
||||
or `https://`. In this mode, when SockJS is enabled, both IFrame and JSONP based
|
||||
transports are disabled. As a consequence, IE6 up to IE9 are not supported when this
|
||||
transports are disabled. As a consequence, IE6 through IE9 are not supported when this
|
||||
mode is enabled.
|
||||
* Allow all origins: to enable this mode, you should provide `*` as allowed origin. In this
|
||||
mode, all transports are available.
|
||||
* Allow all origins: to enable this mode, you should provide `*` as the allowed origin
|
||||
value. In this mode, all transports are available.
|
||||
|
||||
Websocket and SockJS allowed origins can be configured as shown bellow:
|
||||
WebSocket and SockJS allowed origins can be configured as shown bellow:
|
||||
|
||||
[source,java,indent=0]
|
||||
[subs="verbatim,quotes"]
|
||||
|
|
@ -39615,18 +39612,18 @@ SockJS adds minimal message framing. For example the server sends the letter +o+
|
|||
(JSON-encoded array), the letter +h+ ("heartbeat" frame) if no messages flow
|
||||
for 25 seconds by default, and the letter +c+ ("close" frame) to close the session.
|
||||
|
||||
To learn more run an example in a browser and watch HTTP requests.
|
||||
To learn more, run an example in a browser and watch the HTTP requests.
|
||||
The SockJS client allows fixing the list of transports so it is possible to
|
||||
see each transport one at a time. The SockJS client also provides a debug flag
|
||||
which enables helpful messages in the browser console. On the server side enable
|
||||
TRACE logging for `org.springframework.web.socket`.
|
||||
`TRACE` logging for `org.springframework.web.socket`.
|
||||
For even more detail refer to the SockJS protocol
|
||||
http://sockjs.github.io/sockjs-protocol/sockjs-protocol-0.3.3.html[narrated test].
|
||||
|
||||
|
||||
[[websocket-fallback-sockjs-enable]]
|
||||
==== Enable SockJS
|
||||
SockJS is easy to enable through a configuration:
|
||||
SockJS is easy to enable through Java configuration:
|
||||
|
||||
[source,java,indent=0]
|
||||
[subs="verbatim,quotes"]
|
||||
|
|
@ -39693,12 +39690,12 @@ Internet Explorer 8 and 9 are and will remain common for some time. They are
|
|||
a key reason for having SockJS. This section covers important
|
||||
considerations about running in those browsers.
|
||||
|
||||
SockJS client supports Ajax/XHR streaming in IE 8, 9 via Microsoft's
|
||||
The SockJS client supports Ajax/XHR streaming in IE 8 and 9 via Microsoft's
|
||||
http://blogs.msdn.com/b/ieinternals/archive/2010/05/13/xdomainrequest-restrictions-limitations-and-workarounds.aspx[XDomainRequest].
|
||||
That works across domains but does not support sending cookies.
|
||||
Cookies are very often essential for Java applications.
|
||||
However since the SockJS client can be used with many server
|
||||
types (not just Java ones), it needs to know whether cookies do matter.
|
||||
types (not just Java ones), it needs to know whether cookies matter.
|
||||
If so the SockJS client prefers Ajax/XHR for streaming or otherwise it
|
||||
relies on a iframe-based technique.
|
||||
|
||||
|
|
@ -39712,7 +39709,7 @@ cookie. If your application does not need it, you can turn off this option
|
|||
and the SockJS client should choose `xdr-streaming` in IE 8 and 9.
|
||||
|
||||
If you do use an iframe-based transport, and in any case, it is good to know
|
||||
that browsers can be instructed to block the use of iframes on a given page by
|
||||
that browsers can be instructed to block the use of IFrames on a given page by
|
||||
setting the HTTP response header `X-Frame-Options` to `DENY`,
|
||||
`SAMEORIGIN`, or `ALLOW-FROM <origin>`. This is used to prevent
|
||||
https://www.owasp.org/index.php/Clickjacking[clickjacking].
|
||||
|
|
@ -39725,7 +39722,7 @@ In 3.2 the Spring Security XML namespace does not set that header by default
|
|||
but may be configured to do so, and in the future it may set it by default.
|
||||
|
||||
See http://docs.spring.io/spring-security/site/docs/3.2.2.RELEASE/reference/htmlsingle/#headers[Section 7.1. "Default Security Headers"]
|
||||
of the Spring Security documentation for details no how to configure the
|
||||
of the Spring Security documentation for details on how to configure the
|
||||
setting of the `X-Frame-Options` header. You may also check or watch
|
||||
https://jira.spring.io/browse/SEC-2501[SEC-2501] for additional background.
|
||||
====
|
||||
|
|
@ -39739,7 +39736,7 @@ from a CDN location. It is a good idea to configure this option to
|
|||
a URL from the same origin as the application.
|
||||
|
||||
In Java config this can be done as shown below. The XML namespace provides a
|
||||
similar option on the `<websocket:sockjs>` element:
|
||||
similar option via the `<websocket:sockjs>` element:
|
||||
|
||||
[source,java,indent=0]
|
||||
[subs="verbatim,quotes"]
|
||||
|
|
@ -39771,7 +39768,7 @@ https://github.com/sockjs/sockjs-client/tree/v0.3.4[SockJS client] page.
|
|||
==== Heartbeat Messages
|
||||
|
||||
The SockJS protocol requires servers to send heartbeat messages to preclude proxies
|
||||
from concluding a connection is hung. The Spring SockJS configuiration has a property
|
||||
from concluding a connection is hung. The Spring SockJS configuration has a property
|
||||
called `heartbeatTime` that can be used to customize the frequency. By default a
|
||||
heartbeat is sent after 25 seconds assuming no other messages were sent on that
|
||||
connection. This 25 seconds value is in line with the following
|
||||
|
|
@ -39799,19 +39796,19 @@ In Servlet containers this is done through Servlet 3 async support that
|
|||
allows exiting the Servlet container thread processing a request and continuing
|
||||
to write to the response from another thread.
|
||||
|
||||
A specific issue is the Servlet API does not provide notifications for a client
|
||||
A specific issue is that the Servlet API does not provide notifications for a client
|
||||
that has gone away, see https://java.net/jira/browse/SERVLET_SPEC-44[SERVLET_SPEC-44].
|
||||
However, Servlet containers raise an exception on subseqeunt attempts to write
|
||||
to the response. Since Spring's SockJS Service support sever-sent heartbeats (every
|
||||
However, Servlet containers raise an exception on subsequent attempts to write
|
||||
to the response. Since Spring's SockJS Service supports sever-sent heartbeats (every
|
||||
25 seconds by default), that means a client disconnect is usually detected within that
|
||||
time period or earlier if a message are sent more frequently.
|
||||
time period or earlier if messages are sent more frequently.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
As a result network IO failures may occur simply because a client has disconnected, which
|
||||
can fill the log with unnecessary stack traces. Spring makes a best effort to identify
|
||||
such network failures that represent client disconnects (specific to each server) and log
|
||||
a more minimal message using the dedicated log category `DISCONNECTED_CLIENT_LOG_CATEGORY`
|
||||
a minimal message using the dedicated log category `DISCONNECTED_CLIENT_LOG_CATEGORY`
|
||||
defined in `AbstractSockJsSession`. If you need to see the stack traces, set that
|
||||
log category to TRACE.
|
||||
====
|
||||
|
|
@ -39825,7 +39822,7 @@ CORS headers are added automatically unless the presence of CORS headers in the
|
|||
is detected. So if an application is already configured to provide CORS support, e.g.
|
||||
through a Servlet Filter, Spring's SockJsService will skip this part.
|
||||
|
||||
It is also possible to disable the addition of these CORS headers thanks to the
|
||||
It is also possible to disable the addition of these CORS headers via the
|
||||
`suppressCors` property in Spring's SockJsService.
|
||||
|
||||
The following is the list of headers and values expected by SockJS:
|
||||
|
|
@ -39840,17 +39837,17 @@ For the exact implementation see `addCorsHeaders` in `AbstractSockJsService` as
|
|||
as the `TransportType` enum in the source code.
|
||||
|
||||
Alternatively if the CORS configuration allows it consider excluding URLs with the
|
||||
SockJS endpoint prefix thus letting Spring's SockJsService handle it.
|
||||
SockJS endpoint prefix thus letting Spring's `SockJsService` handle it.
|
||||
|
||||
|
||||
[[websocket-fallback-sockjs-client]]
|
||||
==== SockJS Client
|
||||
|
||||
A SockJS Java client is provided in order to connect to remote SockJS endpoints without
|
||||
using a browser. This can be especially useful when there is a need of bidirectional
|
||||
using a browser. This can be especially useful when there is a need for bidirectional
|
||||
communication between 2 servers over a public network, i.e. where network proxies may
|
||||
preclude the use of the WebSocket protocol. A SockJS Java client is also very useful
|
||||
for testing purposes for example to simulate a large number of concurrent users.
|
||||
for testing purposes, for example to simulate a large number of concurrent users.
|
||||
|
||||
The SockJS Java client supports the "websocket", "xhr-streaming", and "xhr-polling"
|
||||
transports. The remaining ones only make sense for use in a browser.
|
||||
|
|
@ -39865,8 +39862,8 @@ An `XhrTransport` by definition supports both "xhr-streaming" and "xhr-polling"
|
|||
from a client perspective there is no difference other than in the URL used to connect
|
||||
to the server. At present there are two implementations:
|
||||
|
||||
* `RestTemplateXhrTransport` uses the RestTemplate for HTTP requests.
|
||||
* `JettyXhrTransport` uses Jetty's HttpClient for HTTP requests.
|
||||
* `RestTemplateXhrTransport` uses Spring's `RestTemplate` for HTTP requests.
|
||||
* `JettyXhrTransport` uses Jetty's `HttpClient` for HTTP requests.
|
||||
|
||||
The example below shows how to create a SockJS client and connect to a SockJS endpoint:
|
||||
|
||||
|
|
@ -39885,7 +39882,7 @@ The example below shows how to create a SockJS client and connect to a SockJS en
|
|||
====
|
||||
SockJS uses JSON formatted arrays for messages. By default Jackson 2 is used and needs
|
||||
to be on the classpath. Alternatively you can configure a custom implementation of
|
||||
`SockJsMessageCodec` and configure it on the SockJsClient.
|
||||
`SockJsMessageCodec` and configure it on the `SockJsClient`.
|
||||
====
|
||||
|
||||
To use the SockJsClient for simulating a large number of concurrent users you will
|
||||
|
|
@ -39927,9 +39924,9 @@ public class WebSocketConfig extends WebSocketMessageBrokerConfigurationSupport
|
|||
[[websocket-stomp]]
|
||||
=== STOMP Over WebSocket Messaging Architecture
|
||||
The WebSocket protocol defines two main types of messages -- text and binary --
|
||||
but leaves their content undefined. Instead it's expected that client and
|
||||
but leaves their content undefined. Instead it's expected that the client and
|
||||
server may agree on using a sub-protocol, i.e. a higher-level protocol that defines
|
||||
the message content. Using a sub-protocol is optional but either way client
|
||||
the message content. Using a sub-protocol is optional but either way the client
|
||||
and server both need to understand how to interpret messages.
|
||||
|
||||
|
||||
|
|
@ -39937,12 +39934,12 @@ and server both need to understand how to interpret messages.
|
|||
[[websocket-stomp-overview]]
|
||||
==== Overview of STOMP
|
||||
http://stomp.github.io/stomp-specification-1.2.html#Abstract[STOMP] is a simple
|
||||
messaging protocol originally created for scripting languages (such as Ruby, Python and
|
||||
Perl) to connect to enterprise message brokers. It is designed to address a
|
||||
subset of commonly used patterns in messaging protocols. STOMP can be used over
|
||||
any reliable 2-way streaming network protocol such as TCP and WebSocket.
|
||||
text-oriented messaging protocol that was originally created for scripting languages
|
||||
(such as Ruby, Python, and Perl) to connect to enterprise message brokers. It is
|
||||
designed to address a subset of commonly used patterns in messaging protocols. STOMP
|
||||
can be used over any reliable 2-way streaming network protocol such as TCP and WebSocket.
|
||||
|
||||
STOMP is a frame based protocol with frames modelled on HTTP. This is the
|
||||
STOMP is a frame based protocol with frames modeled on HTTP. This is the
|
||||
structure of a frame:
|
||||
|
||||
----
|
||||
|
|
@ -39955,7 +39952,7 @@ Body^@
|
|||
|
||||
For example, a client can use the +SEND+ command to send a message or the
|
||||
+SUBSCRIBE+ command to express interest in receiving messages. Both of these commands
|
||||
require a +"destination"+ header that indicates where to send a message to, or likewise
|
||||
require a +"destination"+ header that indicates where to send a message, or likewise
|
||||
what to subscribe to.
|
||||
|
||||
Here is an example of a client sending a request to buy stock shares:
|
||||
|
|
@ -39981,10 +39978,10 @@ destination:/topic/price.stock.*
|
|||
[NOTE]
|
||||
====
|
||||
The meaning of a destination is intentionally left opaque in the STOMP spec. It can
|
||||
be any string and it's entirely up to STOMP servers to define the semantics and
|
||||
the syntax of the destinations that they support. It is very common however, for
|
||||
be any string, and it's entirely up to STOMP servers to define the semantics and
|
||||
the syntax of the destinations that they support. It is very common, however, for
|
||||
destinations to be path-like strings where `"/topic/.."` implies publish-subscribe
|
||||
(__one-to-many__) and `"/queue/"` to implies point-to-point (__one-to-one__) message
|
||||
(__one-to-many__) and `"/queue/"` implies point-to-point (__one-to-one__) message
|
||||
exchanges.
|
||||
====
|
||||
|
||||
|
|
@ -40002,10 +39999,10 @@ destination:/topic/price.stock.MMM
|
|||
|
||||
[NOTE]
|
||||
====
|
||||
It's important to know that a server cannot send unsolicited messages.
|
||||
All messages from a server must be in response to a specific client subscription
|
||||
and the +"subscription-id"+ header of the server message must match
|
||||
the +"id"+ header of the client subscription.
|
||||
It is important to know that a server cannot send unsolicited messages. All messages
|
||||
from a server must be in response to a specific client subscription, and the
|
||||
+"subscription-id"+ header of the server message must match the +"id"+ header of the
|
||||
client subscription.
|
||||
====
|
||||
|
||||
The above overview is intended to provide the most basic understanding of the
|
||||
|
|
@ -40013,13 +40010,13 @@ STOMP protocol. It is recommended to review the protocol
|
|||
http://stomp.github.io/stomp-specification-1.2.html[specification], which is
|
||||
easy to follow and manageable in terms of size.
|
||||
|
||||
The following summarizes the benefits for an application from using STOMP over WebSocket:
|
||||
The following summarizes the benefits for an application of using STOMP over WebSocket:
|
||||
|
||||
* Standard message format
|
||||
* Application-level protocol with support for common messaging patterns
|
||||
* Client-side support, e.g. https://github.com/jmesnil/stomp-websocket[stomp.js], https://github.com/cujojs/msgs[msgs.js]
|
||||
* The ability to interpret, route, and process messages on both client and server-side
|
||||
* The option to plug a message broker -- RabbitMQ, ActiveMQ, many others -- to broadcast messages (explained later)
|
||||
* The ability to interpret, route, and process messages on both the client and server-side
|
||||
* The option to plug in a message broker -- RabbitMQ, ActiveMQ, many others -- to broadcast messages (explained later)
|
||||
|
||||
Most importantly the use of STOMP (vs plain WebSocket) enables the Spring Framework
|
||||
to provide a programming model for application-level use in the same way that
|
||||
|
|
@ -40033,7 +40030,7 @@ The Spring Framework provides support for using STOMP over WebSocket through
|
|||
the +spring-messaging+ and +spring-websocket+ modules. It's easy to enable it.
|
||||
|
||||
Here is an example of configuring a STOMP WebSocket endpoint with SockJS fallback
|
||||
options. The endpoint is available for clients to connect to at URL path `/app/portfolio`:
|
||||
options. The endpoint is available for clients to connect to a URL path `/app/portfolio`:
|
||||
|
||||
[source,java,indent=0]
|
||||
[subs="verbatim,quotes"]
|
||||
|
|
@ -40112,7 +40109,7 @@ Or if connecting via WebSocket (without SockJS):
|
|||
}
|
||||
----
|
||||
|
||||
Note that the stompClient above does not need to specify a `login` and `passcode` headers.
|
||||
Note that the `stompClient` above does not need to specify `login` and `passcode` headers.
|
||||
Even if it did, they would be ignored, or rather overridden, on the server side. See the
|
||||
sections <<websocket-stomp-handle-broker-relay-configure>> and
|
||||
<<websocket-stomp-authentication>> for more information on authentication.
|
||||
|
|
@ -40130,7 +40127,7 @@ https://spring.io/spring-integration[Spring Integration] project and are intende
|
|||
for use as building blocks in messaging applications:
|
||||
|
||||
* {javadoc-baseurl}/org/springframework/messaging/Message.html[Message] --
|
||||
represents a message with headers and a payload.
|
||||
a message with headers and a payload.
|
||||
* {javadoc-baseurl}/org/springframework/messaging/MessageHandler.html[MessageHandler] --
|
||||
a contract for handling a message.
|
||||
* {javadoc-baseurl}/org/springframework/messaging/MessageChannel.html[MessageChannel] --
|
||||
|
|
@ -40139,7 +40136,7 @@ a contract for sending a message enabling loose coupling between senders and rec
|
|||
extends `MessageChannel` and sends messages to registered `MessageHandler` subscribers.
|
||||
* {javadoc-baseurl}/org/springframework/messaging/support/ExecutorSubscribableChannel.html[ExecutorSubscribableChannel] --
|
||||
a concrete implementation of `SubscribableChannel` that can deliver messages
|
||||
asynchronously through a thread pool.
|
||||
asynchronously via a thread pool.
|
||||
|
||||
The provided STOMP over WebSocket config, both Java and XML, uses the above to
|
||||
assemble a concrete message flow including the following 3 channels:
|
||||
|
|
@ -40160,11 +40157,11 @@ the "/app" prefix could route messages to annotated methods while the "/topic"
|
|||
and "/queue" prefixes could route messages to the broker.
|
||||
|
||||
When a message-handling annotated method has a return type, its return
|
||||
value is sent as the payload of a Spring Message to the `"brokerChannel"`.
|
||||
value is sent as the payload of a Spring `Message` to the `"brokerChannel"`.
|
||||
The broker in turn broadcasts the message to clients. Sending a message
|
||||
to a destination can also be done from anywhere in the application with
|
||||
the help of a messaging template. For example a an HTTP POST handling method
|
||||
can broadcast a message to connected clients or a service component may
|
||||
the help of a messaging template. For example, an HTTP POST handling method
|
||||
can broadcast a message to connected clients, or a service component may
|
||||
periodically broadcast stock quotes.
|
||||
|
||||
Below is a simple example to illustrate the flow of messages:
|
||||
|
|
@ -40201,17 +40198,17 @@ Below is a simple example to illustrate the flow of messages:
|
|||
|
||||
----
|
||||
|
||||
The following explains the message flow for the above exmaple:
|
||||
The following explains the message flow for the above example:
|
||||
|
||||
* WebSocket clients connect to the WebSocket endpoint at "/portfolio".
|
||||
* Subscriptions to "/topic/greeting" pass through the "clientInboundChannel"
|
||||
and are forwarded to the broker.
|
||||
* Greetings sent to "/app/greeting" pass through the "clientInboundChannel"
|
||||
and are forwarded to the `GreetingController`. The controller adds the current
|
||||
time and the return value is passed through the "brokerChannel" as message
|
||||
time, and the return value is passed through the "brokerChannel" as a message
|
||||
to "/topic/greeting" (destination is selected based on a convention but can be
|
||||
overridden via `@SendTo`).
|
||||
* The broker in turn broadcasts messages to subscribers and they pass through
|
||||
* The broker in turn broadcasts messages to subscribers, and they pass through
|
||||
the `"clientOutboundChannel"`.
|
||||
|
||||
The next section provides more details on annotated methods including the
|
||||
|
|
@ -40244,7 +40241,7 @@ The following method arguments are supported for `@MessageMapping` methods:
|
|||
* `@Payload`-annotated argument for access to the payload of a message, converted with
|
||||
a `org.springframework.messaging.converter.MessageConverter`.
|
||||
The presence of the annotation is not required since it is assumed by default.
|
||||
Payload method arguments annotated with Validation annotations (like `@Validated`) will
|
||||
Payload method arguments annotated with validation annotations (like `@Validated`) will
|
||||
be subject to JSR-303 validation.
|
||||
* `@Header`-annotated arguments for access to a specific header value along with
|
||||
type conversion using an `org.springframework.core.convert.converter.Converter`
|
||||
|
|
@ -40263,7 +40260,7 @@ the time of the WebSocket HTTP handshake.
|
|||
The return value from an `@MessageMapping` method is converted with a
|
||||
`org.springframework.messaging.converter.MessageConverter` and used as the body
|
||||
of a new message that is then sent, by default, to the `"brokerChannel"` with
|
||||
the same destination as the client message but using the prefix "/topic" by
|
||||
the same destination as the client message but using the prefix `"/topic"` by
|
||||
default. An `@SendTo` message level annotation can be used to specify any
|
||||
other destination instead.
|
||||
|
||||
|
|
@ -40284,7 +40281,7 @@ the specified target destination.
|
|||
[[websocket-stomp-handle-send]]
|
||||
==== Sending Messages
|
||||
|
||||
What if you wanted to send messages to connected clients from any part of the
|
||||
What if you want to send messages to connected clients from any part of the
|
||||
application? Any application component can send messages to the `"brokerChannel"`.
|
||||
The easiest way to do that is to have a `SimpMessagingTemplate` injected, and
|
||||
use it to send messages. Typically it should be easy to have it injected by
|
||||
|
|
@ -40319,7 +40316,7 @@ bean of the same type exists.
|
|||
[[websocket-stomp-handle-simple-broker]]
|
||||
==== Simple Broker
|
||||
|
||||
The built-in, simple, message broker handles subscription requests from clients,
|
||||
The built-in, simple message broker handles subscription requests from clients,
|
||||
stores them in memory, and broadcasts messages to connected clients with matching
|
||||
destinations. The broker supports path-like destinations, including subscriptions
|
||||
to Ant-style destination patterns.
|
||||
|
|
@ -40337,14 +40334,14 @@ See <<websocket-stomp-destination-separator>>.
|
|||
==== Full-Featured Broker
|
||||
|
||||
The simple broker is great for getting started but supports only a subset of
|
||||
STOMP commands (e.g. no acks, receipts, etc), relies on a simple message
|
||||
sending loop, and is not suitable for clustering. Instead, applications can
|
||||
upgrade to using a full-featured message broker.
|
||||
STOMP commands (e.g. no acks, receipts, etc.), relies on a simple message
|
||||
sending loop, and is not suitable for clustering. As an alternative, applications
|
||||
can upgrade to using a full-featured message broker.
|
||||
|
||||
Check the STOMP documentation for your message broker of choice (e.g.
|
||||
http://www.rabbitmq.com/stomp.html[RabbitMQ],
|
||||
http://activemq.apache.org/stomp.html[ActiveMQ], or other), install and run the
|
||||
broker with STOMP support enabled. Then enable the STOMP broker relay in the
|
||||
http://activemq.apache.org/stomp.html[ActiveMQ], etc.), install the broker,
|
||||
and run it with STOMP support enabled. Then enable the STOMP broker relay in the
|
||||
Spring configuration instead of the simple broker.
|
||||
|
||||
Below is example configuration that enables a full-featured broker:
|
||||
|
|
@ -40398,9 +40395,9 @@ The "STOMP broker relay" in the above configuration is a Spring
|
|||
http://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/messaging/MessageHandler.html[MessageHandler]
|
||||
that handles messages by forwarding them to an external message broker.
|
||||
To do so it establishes TCP connections to the broker, forwards all
|
||||
messages to it, and reversely forwards all messages received
|
||||
messages to it, and then forwards all messages received
|
||||
from the broker to clients through their WebSocket sessions. Essentially
|
||||
it acts as a "relay" forwarding messages in both directions.
|
||||
it acts as a "relay" that forwards messages in both directions.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
|
|
@ -40408,7 +40405,7 @@ Please add a dependency on `org.projectreactor:reactor-net` for TCP connection m
|
|||
====
|
||||
|
||||
Furthermore, application components (e.g. HTTP request handling methods,
|
||||
business services, etc) can also send messages to the broker relay, as described
|
||||
business services, etc.) can also send messages to the broker relay, as described
|
||||
in <<websocket-stomp-handle-send>>, in order to broadcast messages to
|
||||
subscribed WebSocket clients.
|
||||
|
||||
|
|
@ -40427,14 +40424,14 @@ is exposed in both the XML namespace and the Java config as the
|
|||
The STOMP broker relay also creates a separate TCP connection for every connected
|
||||
WebSocket client. You can configure the STOMP credentials to use for all TCP
|
||||
connections created on behalf of clients. This is exposed in both the XML namespace
|
||||
and the Java config as the `clientLogin`/`clientPasscode` properties with default
|
||||
and the Java config as the ++clientLogin++/++clientPasscode++ properties with default
|
||||
values ++guest++/++guest++.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
The STOMP broker relay always sets the `login` and `passcode` headers on every CONNECT
|
||||
frame it forwards to the broker on behalf of clients. Therefore WebSocket clients
|
||||
need not set those headers, they will be ignored. As the following section explains
|
||||
The STOMP broker relay always sets the `login` and `passcode` headers on every `CONNECT`
|
||||
frame that it forwards to the broker on behalf of clients. Therefore WebSocket clients
|
||||
need not set those headers; they will be ignored. As the following section explains,
|
||||
instead WebSocket clients should rely on HTTP authentication to protect the WebSocket
|
||||
endpoint and establish the client identity.
|
||||
====
|
||||
|
|
@ -40454,7 +40451,7 @@ stop trying to send messages when there is no active "system" connection.
|
|||
====
|
||||
|
||||
The STOMP broker relay can also be configured with a `virtualHost` property.
|
||||
The value of this property will be set as the `host` header of every CONNECT frame
|
||||
The value of this property will be set as the `host` header of every `CONNECT` frame
|
||||
and may be useful for example in a cloud environment where the actual host to which
|
||||
the TCP connection is established is different from the host providing the
|
||||
cloud-based STOMP service.
|
||||
|
|
@ -40463,7 +40460,7 @@ cloud-based STOMP service.
|
|||
==== Using Dot as Separator in `@MessageMapping` Destinations
|
||||
|
||||
Although slash-separated path patterns are familiar to web developers, in messaging
|
||||
it is common to use "." as separator for example in the names of topics, queues,
|
||||
it is common to use a "." as the separator, for example in the names of topics, queues,
|
||||
exchanges, etc. Applications can also switch to using "." (dot) instead of "/" (slash)
|
||||
as the separator in `@MessageMapping` mappings by configuring a custom `AntPathMatcher`.
|
||||
|
||||
|
|
@ -40474,7 +40471,7 @@ In Java config:
|
|||
----
|
||||
@Configuration
|
||||
@EnableWebSocketMessageBroker
|
||||
public class WebsocketConfig extends AbstractWebSocketMessageBrokerConfigurer {
|
||||
public class WebSocketConfig extends AbstractWebSocketMessageBrokerConfigurer {
|
||||
|
||||
// ...
|
||||
|
||||
|
|
@ -40549,8 +40546,8 @@ to STOMP/WebSocket are already automatically protected and require authenticatio
|
|||
Moreover the page that opens the WebSocket connection is itself likely protected
|
||||
and so by the time of the actual handshake, the user should have been authenticated.
|
||||
|
||||
When a WebSocket handshake is made and a new WebSocket session created,
|
||||
Spring's WebSocket support automatically transfers the `java.security.Principal`
|
||||
When a WebSocket handshake is made and a new WebSocket session is created,
|
||||
Spring's WebSocket support automatically propagates the `java.security.Principal`
|
||||
from the HTTP request to the WebSocket session. After that every message flowing
|
||||
through the application on that WebSocket session is enriched with
|
||||
the user information. It's present in the message as a header.
|
||||
|
|
@ -40561,8 +40558,8 @@ Note that even though the STOMP `CONNECT` frame has "login" and "passcode" heade
|
|||
that can be used for authentication, Spring's STOMP WebSocket support ignores them
|
||||
and currently expects users to have been authenticated already via HTTP.
|
||||
|
||||
In some cases it may be useful to assign an identity to WebSocket session even
|
||||
when the user has not formally authenticated. For example a mobile app might
|
||||
In some cases it may be useful to assign an identity to a WebSocket session even
|
||||
when the user has not been formally authenticated. For example, a mobile app might
|
||||
assign some identity to anonymous users, perhaps based on geographical location.
|
||||
The do that currently, an application can sub-class `DefaultHandshakeHandler`
|
||||
and override the `determineUser` method. The custom handshake handler can then
|
||||
|
|
@ -40573,8 +40570,8 @@ be plugged in (see examples in <<websocket-server-deployment>>).
|
|||
[[websocket-stomp-user-destination]]
|
||||
==== User Destinations
|
||||
|
||||
An application can send messages targeting a specific user.
|
||||
Spring's STOMP support recognizes destinations prefixed with `"/user/"`.
|
||||
An application can send messages targeting a specific user, and Spring's STOMP support
|
||||
recognizes destinations prefixed with `"/user/"` for this purpose.
|
||||
For example, a client might subscribe to the destination `"/user/queue/position-updates"`.
|
||||
This destination will be handled by the `UserDestinationMessageHandler` and
|
||||
transformed into a destination unique to the user session,
|
||||
|
|
@ -40591,7 +40588,7 @@ send messages targeting a specific user without necessarily knowing anything mor
|
|||
than their name and the generic destination. This is also supported through an
|
||||
annotation as well as a messaging template.
|
||||
|
||||
For example message-handling method can send messages to the user associated with
|
||||
For example, a message-handling method can send messages to the user associated with
|
||||
the message being handled through the `@SendToUser` annotation:
|
||||
|
||||
[source,java,indent=0]
|
||||
|
|
@ -40609,7 +40606,7 @@ public class PortfolioController {
|
|||
}
|
||||
----
|
||||
|
||||
If the user has more than one sessions, by default all of the sessions subscribed
|
||||
If the user has more than one session, by default all of the sessions subscribed
|
||||
to the given destination are targeted. However sometimes, it may be necessary to
|
||||
target only the session that sent the message being handled. This can be done by
|
||||
setting the `broadcast` attribute to false, for example:
|
||||
|
|
@ -40645,8 +40642,8 @@ session that sent the message being handled.
|
|||
====
|
||||
|
||||
It is also possible to send a message to user destinations from any application
|
||||
component by injecting the `SimpMessageTemplate` created by the Java config or
|
||||
XML namespace, for example (the bean name is "brokerMessagingTemplate` if required
|
||||
component by injecting the `SimpMessagingTemplate` created by the Java config or
|
||||
XML namespace, for example (the bean name is `"brokerMessagingTemplate"` if required
|
||||
for qualification with `@Qualifier`):
|
||||
|
||||
[source,java,indent=0]
|
||||
|
|
@ -40655,10 +40652,10 @@ for qualification with `@Qualifier`):
|
|||
@Service
|
||||
public class TradeServiceImpl implements TradeService {
|
||||
|
||||
private final SimpMessageTemplate messagingTemplate;
|
||||
private final SimpMessagingTemplate messagingTemplate;
|
||||
|
||||
@Autowired
|
||||
public TradeServiceImpl(SimpMessageTemplate messagingTemplate) {
|
||||
public TradeServiceImpl(SimpMessagingTemplate messagingTemplate) {
|
||||
this.messagingTemplate = messagingTemplate;
|
||||
}
|
||||
|
||||
|
|
@ -40678,7 +40675,8 @@ documentation on how to manage inactive queues, so that when the user session is
|
|||
over, all unique user queues are removed. For example, RabbitMQ creates auto-delete
|
||||
queues when destinations like `/exchange/amq.direct/position-updates` are used.
|
||||
So in that case the client could subscribe to `/user/exchange/amq.direct/position-updates`.
|
||||
ActiveMQ has http://activemq.apache.org/delete-inactive-destinations.html[configuration options]
|
||||
Similarly, ActiveMQ has
|
||||
http://activemq.apache.org/delete-inactive-destinations.html[configuration options]
|
||||
for purging inactive destinations.
|
||||
====
|
||||
|
||||
|
|
@ -40694,7 +40692,7 @@ received by implementing Spring's `ApplicationListener` interface.
|
|||
* `BrokerAvailabilityEvent` -- indicates when the broker becomes available/unavailable.
|
||||
While the "simple" broker becomes available immediately on startup and remains so while
|
||||
the application is running, the STOMP "broker relay" may lose its connection
|
||||
to the full featured broker for example if the broker is restarted. The broker relay
|
||||
to the full featured broker, for example if the broker is restarted. The broker relay
|
||||
has reconnect logic and will re-establish the "system" connection to the broker
|
||||
when it comes back, hence this event is published whenever the state changes from connected
|
||||
to disconnected and vice versa. Components using the `SimpMessagingTemplate` should
|
||||
|
|
@ -40713,14 +40711,14 @@ STOMP session can be considered fully established.
|
|||
* `SessionSubscribeEvent` -- published when a new STOMP SUBSCRIBE is received.
|
||||
* `SessionUnsubscribeEvent` -- published when a new STOMP UNSUBSCRIBE is received.
|
||||
* `SessionDisconnectEvent` -- published when a STOMP session ends. The DISCONNECT may
|
||||
have been sent from the client or it may also be automatically generated when the
|
||||
have been sent from the client, or it may also be automatically generated when the
|
||||
WebSocket session is closed. In some cases this event may be published more than once
|
||||
per session. Components should be idempotent to multiple disconnect events.
|
||||
per session. Components should be idempotent with regard to multiple disconnect events.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
When using a full-featured broker, the STOMP "broker relay" automatically reconnects the
|
||||
"system" connection should the broker become temporarily unavailable. Client connections
|
||||
"system" connection in case the broker becomes temporarily unavailable. Client connections
|
||||
however are not automatically reconnected. Assuming heartbeats are enabled, the client
|
||||
will typically notice the broker is not responding within 10 seconds. Clients need to
|
||||
implement their own reconnect logic.
|
||||
|
|
@ -40735,7 +40733,7 @@ to intercept inbound messages:
|
|||
----
|
||||
@Configuration
|
||||
@EnableWebSocketMessageBroker
|
||||
public class WebsocketConfig extends AbstractWebSocketMessageBrokerConfigurer {
|
||||
public class WebSocketConfig extends AbstractWebSocketMessageBrokerConfigurer {
|
||||
|
||||
@Override
|
||||
public void configureClientInboundChannel(ChannelRegistration registration) {
|
||||
|
|
@ -40828,7 +40826,7 @@ public class MyController {
|
|||
}
|
||||
----
|
||||
|
||||
As with any custom scope, Spring initializes a new MyBean instance the first
|
||||
As with any custom scope, Spring initializes a new `MyBean` instance the first
|
||||
time it is accessed from the controller and stores the instance in the WebSocket
|
||||
session attributes. The same instance is returned subsequently until the session
|
||||
ends. WebSocket-scoped beans will have all Spring lifecycle methods invoked as
|
||||
|
|
@ -40896,7 +40894,8 @@ The general idea is that at any given time only a single thread may be used
|
|||
to send to a client. All additional messages meanwhile get buffered and you
|
||||
can use these properties to decide how long sending a message is allowed to
|
||||
take and how much data can be buffered in the mean time. Please review the
|
||||
Javadoc of XML schema for this configuration for important additional details.
|
||||
Javadoc and documentation of the XML schema for this configuration for
|
||||
important additional details.
|
||||
|
||||
Here is example configuration:
|
||||
|
||||
|
|
@ -40939,8 +40938,8 @@ Here is example configuration:
|
|||
|
||||
The WebSocket transport configuration shown above can also be used to configure the
|
||||
maximum allowed size for incoming STOMP messages. Although in theory a WebSocket
|
||||
message can be almost unlimited in size, in pracitce WebSocket servers impose
|
||||
limits. For example 8K on Tomcat and 64K on Jetty. For this reason STOMP clients
|
||||
message can be almost unlimited in size, in practice WebSocket servers impose
|
||||
limits -- for example, 8K on Tomcat and 64K on Jetty. For this reason STOMP clients
|
||||
such as stomp.js split larger STOMP messages at 16K boundaries and send them as
|
||||
multiple WebSocket messages thus requiring the server to buffer and re-assemble.
|
||||
|
||||
|
|
@ -41005,9 +41004,9 @@ When using `@EnableWebSocketMessageBroker` or `<websocket:message-broker>` key
|
|||
infrastructure components automatically gather stats and counters that provide
|
||||
important insight into the internal state of the application. The configuration
|
||||
also declares a bean of type `WebSocketMessageBrokerStats` that gathers all
|
||||
available information in one place and by default logs it at INFO once
|
||||
available information in one place and by default logs it at `INFO` level once
|
||||
every 30 minutes. This bean can be exported to JMX through Spring's
|
||||
`MBeanExporter` for viewing at runtime for example through JDK's jconsole.
|
||||
`MBeanExporter` for viewing at runtime, for example through JDK's `jconsole`.
|
||||
Below is a summary of the available information.
|
||||
|
||||
Client WebSocket Sessions::
|
||||
|
|
@ -41066,7 +41065,7 @@ full end-to-end tests that involve running a client and a server.
|
|||
The two approaches are not mutually exclusive. On the contrary each has a place
|
||||
in an overall test strategy. Server-side tests are more focused and easier to write
|
||||
and maintain. End-to-end integration tests on the other hand are more complete and
|
||||
test much more but they're also more involved to write and maintain.
|
||||
test much more, but they're also more involved to write and maintain.
|
||||
|
||||
The simplest form of server-side tests is to write controller unit tests. However
|
||||
this is not useful enough since much of what a controller does depends on its
|
||||
|
|
@ -41094,9 +41093,10 @@ The second approach is to create end-to-end integration tests. For that you will
|
|||
to run a WebSocket server in embedded mode and connect to it as a WebSocket client
|
||||
sending WebSocket messages containing STOMP frames.
|
||||
The https://github.com/rstoyanchev/spring-websocket-portfolio/tree/master/src/test/java/org/springframework/samples/portfolio/web[tests for the stock portfolio]
|
||||
sample application also demonstrate this approach using Tomcat as the embedded
|
||||
sample application also demonstrates this approach using Tomcat as the embedded
|
||||
WebSocket server and a simple STOMP client for test purposes.
|
||||
|
||||
|
||||
[[spring-integration]]
|
||||
= Integration
|
||||
[partintro]
|
||||
|
|
|
|||
Loading…
Reference in New Issue