root
/
spring-framework
mirror of https://github.com/spring-projects/spring-framework.git
1
0
Fork 0
Code Issues Actions 8 Packages Projects Releases Wiki Activity

Document STOMP-related ApplicationContext events 

Issue: SPR-11672
This commit is contained in:
Rossen Stoyanchev 2014-04-28 21:57:56 -04:00
parent be5f2a8b4e
commit 86785f340e
1 changed files with 44 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

45
src/asciidoc/index.adoc
View File

@ -37997,7 +37997,7 @@ it acts as a "relay" forwarding messages in both directions.
[NOTE]
====
Please add a dependency on `org.projectreactor:reactor-tcp` for TCP connection management.
Please add a dependency on `org.projectreactor:reactor-net` for TCP connection management.
====
Furthermore, application components (e.g. HTTP request handling methods,
@ -38124,6 +38124,49 @@ for purging inactive destinations.
[[websocket-stomp-appplication-context-events]]
==== ApplicationContext Events
The STOMP messaging support publishes the `ApplicationContext` events listed below.
To subscribe to receive one or more of these events a Spring managed component can
implement Spring's `ApplicationListener` interface. The events are:
* `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
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
subscribe to this event and avoid sending messages at times when the broker is not
available. In any case they should be prepared to handle `MessageDeliveryException`
when sending a message.
* `SessionConnectEvent` -- published when a new STOMP CONNECT is received
indicating the start of a new client session. The event contains the message representing the
connect including the session id, user information (if any), and any custom headers the client
may have sent. This is useful for tracking client sessions. Components subscribed
to this event can wrap the contained message using `SimpMessageHeaderAccessor` or
`StompMessageHeaderAccessor`.
* `SessionConnectedEvent` -- published shortly after a `SessionConnectEvent` when the
broker has sent a STOMP CONNECTED frame in response to the CONNECT. At this point the
STOMP session can be considered fully established.
* `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
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.
[NOTE]
====
When using a full-featured broker, the STOMP "broker relay" automatically reconnects the
"system" connection should the broker become 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.
====
[[websocket-stomp-configuration-performance]]
==== Configuration and Performance