SockJS receive stomp messages from spring websocket out of order

Question

I am trying to streaming time series data using Springframework SimpMessagingTemplate (default Stomp implementation) to broadcast messages to a topic that the SockJS client subscribed to. However, the messages is received out of order. The server is single thread and messages are sent in ascending order by their timestamps. The client somehow received the messages out of the order.

I am using the latest release version of both stompjs and springframework (4.1.6 release).

Answer 1

looks like there is a built in striped executor, so just enable it:

@Override
protected void configureMessageBroker(MessageBrokerRegistry registry) {
    // ...
    registry.setPreservePublishOrder(true);
}

https://docs.spring.io/spring/docs/current/spring-framework-reference/web.html#websocket-stomp-ordered-messages

Answer 2

It's Spring web socket design problem. To receive messages in valid order you have to set corePoolSize of websocket clients to 1.

@Configuration
@EnableWebSocketMessageBroker
public class WebSocketMessageBrokerConfiguration extends AbstractWebSocketMessageBrokerConfigurer {

    @Override
    public void configureClientOutboundChannel(ChannelRegistration registration) {
        registration.taskExecutor().corePoolSize(1);
    }

    @Override
    public void configureClientInboundChannel(ChannelRegistration registration) {
        registration.taskExecutor().corePoolSize(1);
    }
}

Answer 3

Found the root cause of this issue. The messages were sending in "correct" order from the application implementation perspective (I.e, convertAndSend() are called in one thread or at least thread safe fashion"). However, Springframework web socket uses reactor-tcp implementation which will process the messages on clientOutboundChannel from the thread pool. Thus the messages can be written to the tcp socket in different order that they are arrived. When I configured the web socket to limit 1 thread for the clientOutboundChannel, the order is preserved.

This problem is not in the SocketJS but a limitation of current Spring web socket design.