The reactive approach to WebSocket is necessary when the requirement for client-server messaging involves an unbounded number of request streams and event subscriptions. The request handler instances can be instantiated infinitely, wherein each is being managed by an assigned thread. Then, these instances can be shared among existing WebSocket connections triggered by the client. To confirm this behavior, open the ch12-messenger.log project and study this audit from the request handler created in the preceding recipe:

    18:14:27.878 [reactor-http-nio-2] INFO  reactor.Mono.DelayElement.1 - 
          onSubscribe([Fuseable] MonoDelayElement.DelayElementSubscriber)
    18:14:27.879 [reactor-http-nio-2] INFO  reactor.Mono.DelayElement.1 - 
         request(unbounded)
  

The reactive data exchange should be managed by a reactive application server that supports the RequestUpgradeStrategy component, which is a kind of container needed for the Reactive WebSocket handshake. Unfortunately, Tomcat 9.x does not support RequestUpgradeStrategy by default, which means it is not capable of recognizing Reactive sessions with Flux<WebSocketMessage> as payloads.