Fix session initialization concurrency issue in SockJS session implementations [SPR-11916] #16535
Description
Rossen Stoyanchev opened SPR-11916 and commented
There is a general assumption in WebSocket servers that applications must synchronize sending messages through the session (and the STOMP messaging support takes care of that).
The same assumption also applies when using SockJS, which is just another WebSocketSession implementation. However, load testing with a high number of concurrent users using the new SockJS client #15423 has revealed a few cases specific to SockJS.
For example when the SockJS session relies on an actual WebSocket it must ensure the application WebSocketHandler is notified of the open session before sending the open frame. Otherwise it is technically possible for the WebSocketHandler to receive messages before the afterConnectionEstablished callback.
The same applies when the SockJS session relies on HTTP long polling except in this case there is further contention not just among application threads sending messages but also between those and periodic long polling requests from the client to resume receiving messages.
Affects: 4.0.5