The relay holds broker TCP connections with configured credentials, while the browser's user identity comes from HTTP authentication.
Spring STOMP broker relay: credentials and broker availability are separate from user identity
Two kinds of connection
The relay keeps a system connection for application-originated messages and a broker connection for each connected WebSocket client. It sets configured broker login and passcode values on forwarded CONNECT frames; browser-supplied STOMP credentials are not the trusted user identity. Handshake authentication and destination authorization still decide which browser may send or subscribe. Broker credentials belong in secret configuration, not browser JavaScript.
Know when the system link is down
The relay emits BrokerAvailabilityEvent when its system connection changes availability. A producer should not report a notification as delivered merely because it called a messaging template while the broker was unavailable. Persist required events first and retry delivery from durable state. The relay reconnects, but reconnecting does not replay an event that the application failed to store. Multi-instance routing and client recovery complete the path.
Test a broker interruption
Connect two browsers through separate app replicas, stop the broker, attempt an application notification, then restore it. Assert an availability signal, bounded producer behavior, reconnection, and reconciliation of missed data. The configuration sketch omits TLS and credential rotation; those need deployment tests.
Implementation sketch
registry.enableStompBrokerRelay("/topic", "/queue")
.setRelayHost("broker.internal")
.setSystemLogin(systemLogin)
.setSystemPasscode(systemPasscode)
.setClientLogin(clientLogin)
.setClientPasscode(clientPasscode);Cost and verification
Each WebSocket client adds a broker TCP connection. Broker capacity and application socket capacity must both cover peak concurrent sessions; reconnection can create a burst after an outage.
Common Mistakes
- Do not put broker passcodes in STOMP frames sent by the browser.
- Do not treat broker availability as proof a particular client received a message.
- Do not assume reconnection replays application events that were never persisted.
Read next
Spring WebSocket STOMP identity: authenticate the handshake, authorize destinations, Spring STOMP simple broker versus relay: the multi-instance boundary, Spring WebSocket reconnect: recover state after an unobserved gap, Spring outbox retry budget: park a poison event for inspection.
