How do you quickly close a nonresponsive websocket in Java Spring Tomcat?

Question

I have a real-time application with clients using websockets to connect with a Spring Framework server, which is running Spring Boot Tomcat. I want the server to quickly (within 5 seconds) detect when a client stops responding due to a network disconnect or other issue and close the websocket.

I have tried

1. Setting the max session idle timeout as described in the documentation as "Configuring the WebSocket Engine" http://docs.spring.io/spring/docs/current/spring-framework-reference/html/websocket.html

   @Bean
   public WebSocketHandler clientHandler() {
       return new PerConnectionWebSocketHandler(ClientHandler.class);
   }
   @Bean
   public ServletServerContainerFactoryBean createWebSocketContainer() {
       ServletServerContainerFactoryBean container = 
           new ServletServerContainerFactoryBean();
       container.setMaxSessionIdleTimeout(5000);
       container.setAsyncSendTimeout(5000);
       return container;
   }
   

I am not sure this is implemented correctly because I do not see the link between the ServletServerContainerFactoryBean and my generation of ClientHandlers.

2. Sending ping messages from server every 2.5 seconds. After I manually disconnect the client by breaking the network connection, the server happily sends pings for another 30+ seconds until a transport error appears.

3. 1 and 2 simultaneously

4. 1 and 2 and setting server.session-timeout = 5 in application.properties

My methodology for testing this is to:

1. Connect a websocket from a laptop client to the Tomcat server
2. Turn off network connection on the laptop using the physical switch
3. Wait for Tomcat server events

How does a Spring FrameworkTomcat server quickly detect that a client has been disconnected or not responding to close the websocket?

Answer 1

Application Events may help you.

PS: Annotation driven events

PS2: I made an example project for you

Answer 2

ServletServerContainerFactoryBean simply configures the underlying JSR-356 WebSocketContainer through Spring configuration on startup. If you peek inside you'll see it's trivial.

From what I can see in Tomcat code about the handling of maxSessionIdleTimeout, the WsWebSocketContainer#backgroundProcess() method runs every 10 seconds by default to see if there are expired sessions.

I suspect also the pings you're sending from the server are making the session appear active, hence not helping with regards to the idle session timeout configuration.

As to why Tomcat doesn't realize the client is disconnected sooner, I can't really say. In my experience if a client closes a WebSocket connection or if I kill the browser it's detected immediately. In any case that's more to do with Tomcat not Spring.

Answer 3

The approach I eventually took was to implement an application-layer ping-pong protocol.

• The server sends a ping message with period p to the client.
• The client responds to each ping message with a pong message.
• If the server sends more than n ping messages without receiving a pong response, it generates a timeout event.
• The client can also generate a timeout event if it does not receive a ping message in n*p time.

There should be a much simpler way of implementing this using timeouts in the underlying TCP connection.

Answer 4

As the question and the top-voted answer are quite old, wanted to add the easiest way to achieve the same with spring - websocket implementation.

Refer section 4.4.8. Simple Broker

@Configuration
@EnableWebSocketMessageBroker
public class WebSocketConfig implements WebSocketMessageBrokerConfigurer {

    private TaskScheduler messageBrokerTaskScheduler;

    @Autowired
    public void setMessageBrokerTaskScheduler(TaskScheduler taskScheduler) {
        this.messageBrokerTaskScheduler = taskScheduler;
    }

    @Override
    public void configureMessageBroker(MessageBrokerRegistry registry) {

        registry.enableSimpleBroker("/queue/", "/topic/")
                .setHeartbeatValue(new long[] {10000, 20000})
                .setTaskScheduler(this.messageBrokerTaskScheduler);

        // ...
    }
}

When returning the connect response frame, the websocket-server needs to send the hearbeat params to enable ping from the clientside.

If you are using SOCKJS implementation on the clientside, then no additional code is needed to add align to PING/PONG implementation.