Spring STOMP slow clients: send buffer and message-size limits

The socket is not an infinite queue

A warehouse dashboard can disconnect while the server is broadcasting frequent stock events. Until that connection is closed, outbound frames can accumulate. Spring's WebSocket transport supports a send-time limit and a send-buffer-size limit; when the send limit is exceeded, the session is closed. The inbound message-size limit protects the application from oversized STOMP payloads, but it does not replace HTTP handshake controls.

Set a product policy

If the dashboard only needs the latest stock total, publishing every intermediate event is wasteful. Coalesce by SKU or send a compact invalidation and let the client refetch. A bounded message stream and reconnect snapshot are more predictable than trying to buffer an hour of updates. Broker choice affects where messages queue, while admission control applies to producers.

Load-test a deliberately stalled reader

Open one client that stops consuming, keep several healthy clients, and publish at the expected peak rate. Verify the stalled session is closed without delaying healthy recipients or exhausting heap. Inspect transport counters, connection count and oldest pending frame age. The example values are a planning start, not a measured safe setting for this deployment.

Implementation sketch

@Override
public void configureWebSocketTransport(WebSocketTransportRegistration transport) {
    transport.setSendTimeLimit(8_000);
    transport.setSendBufferSizeLimit(512 * 1024);
    transport.setMessageSizeLimit(64 * 1024);
}

Cost and verification

The buffer cap bounds retained bytes per slow session; total memory still scales with concurrent sessions. A low cap can disconnect clients on transient network stalls, so measure production-shaped traffic.

Common Mistakes

• Do not interpret a successful send call as proof the browser consumed the frame.
• Do not increase buffers without multiplying the limit by expected connection count.
• Do not use transport limits as a substitute for an event retention or replay policy.

Read next

Spring WebSocket and STOMP: authenticate the handshake, authorize messages, Spring WebSocket STOMP identity: authenticate the handshake, authorize destinations, Spring STOMP simple broker versus relay: the multi-instance boundary, Spring async work has two failure points: submission and completion.