WebSocket Heartbeats and Connection Management
Fast recall
Quick revision
Core answer
Whether the candidate understands that WebSocket connections can go silently stale and how to detect and handle that.
Assuming a closed browser tab always triggers a clean WebSocket close frame — TCP connections can linger for minutes without heartbeats.
Explain the difference between STOMP-level heart-beating and WebSocket protocol-level ping/pong, and how SockJS adds its own heartbeat layer on top.
Interview-ready guide
Interview answer
TCP does not tell you when a connection dies silently. A laptop lid closes, a mobile network switches towers, a NAT gateway purges an idle mapping — in all these cases, the server holds resources for a client that is gone. Without heartbeats, ghost sessions survive until the OS TCP keepalive fires, which defaults to two hours on Linux.
STOMP heartbeats — the application-layer solution:
- Configure
setHeartbeatValue(new long[]{10000, 10000})and both sides exchange a single newline character every 10 seconds; if the expected beat is missed, the connection is declared dead and cleaned up - The zero-zero default disables heartbeats entirely — safe for localhost, dangerous in production where network failures can leave hundreds of ghost sessions accumulating
Three independent heartbeat layers:
- STOMP-level beats visible to your broker — controlled by the heartbeat configuration on the message broker relay
- WebSocket ping/pong frames — handled by the Netty or Jetty container, independent of STOMP; keeps the TCP connection alive and detects failures at the WebSocket protocol level
- SockJS
hframes — the 25-second heartbeat that keeps HTTP fallback transports alive through proxies; setting it higher than the proxy's idle timeout results in silent drops for long-polling clients - Misconfiguring one layer doesn't affect the others; all three need to be tuned correctly
Session lifecycle cleanup:
SessionDisconnectEventis the only reliable cleanup hook — fired for both clean disconnections and server-detected heartbeat failures; clean up presence maps, message buffers, and session registries hereCloseStatus 1006(no close frame received) signals network-level disconnections rather than clean user navigations; a spike in 1006 codes indicates infrastructure issues like NAT timeouts or load balancer kills
I recommend 10-second STOMP heartbeats for all production deployments, and always implementing SessionDisconnectEvent cleanup rather than relying on clients to send clean disconnection frames.
WebSocket Heartbeats and Connection Management
Direct Answer
WebSocket heartbeats use STOMP heart-beat headers or WebSocket ping/pong frames to detect stale connections. In Spring, configure heart-beating on the broker and use ApplicationListener<SessionDisconnectEvent> or WebSocketHandlerDecorator to track and clean up disconnected sessions.
Common Mistakes & Pitfalls
Assuming a closed browser tab always triggers a clean WebSocket close frame — TCP connections can linger for minutes without heartbeats.
Check your understanding
Answer these without looking back at the article.
- What is the difference between a STOMP heartbeat and a WebSocket ping/pong frame?
- How do you implement a presence indicator (online/offline) using WebSocket events in a distributed system?
- What CloseStatus codes should you monitor for in production and what do they indicate?
Related interview prep categories
1Want a guided curriculum order?
These modules are also sequenced in our flagship backend interview track — open it when you prefer an ordered path instead of browsing by topic.