Spring Spring Boot WebSocket Broker does not sends CONNECTED frame

I recently faced and issue, unfortunately on production environment, when my Spring Boot Server was not sending response of CONNECT frame (i.e CONNECTED frame). It first started happening occasionally but later on all the CONNECT requests sent by the browser were not replied to.

On console I was able to see following log

After some investigating, I found out that inboundChannel queue was holding many requests at that time. I believe this was the reason.

2022-06-01 18:22:59,943 INFO Thread-id-74- springframework.web.socket.config.WebSocketMessageBrokerStats: WebSocketSession[130 current WS(129)-HttpStream(1)-HttpPoll(0), 225 total, 0 closed abnormally (0 connect failure, 0 send limit, 2 transport error)], stompSubProtocol[processed CONNECT(220)-CONNECTED(132)-DISCONNECT(0)], stompBrokerRelay[null], inboundChannel[pool size = 2, active threads = 2, queued tasks = 10774, completed tasks = 31806], outboundChannel[pool size = 2, active threads = 0, queued tasks = 0, completed tasks = 570895], sockJsScheduler[pool size = 1, active threads = 1, queued tasks = 134, completed tasks = 1985]

I was wondering what might be the cause of the issue, what can cause queuing in the inboundChannel queue?

here is my current STOMP config on my angular application.

const config: StompJS.StompConfig = {
      brokerURL: this.serverUrl,
      connectHeaders: {
        ccid: this.cookieService.get('ccid'),
        username: `${this.globalContext.get('me')['username']}`,
      },
      debug: (str) => {
        this.loggerService.log(this.sessionId, ' | ', str);
      },
      webSocketFactory: () => {
        return new SockJS(this.serverUrl);
      },
      logRawCommunication: true,
      reconnectDelay: 3000,
      heartbeatIncoming: 100,
      heartbeatOutgoing: 100,
      discardWebsocketOnCommFailure: true,
      connectionTimeout: 4000
    };

Comment From: rstoyanchev

More investigation is necessary to narrow down what happens, and this issue generally would be more appropriate for StackOverflow until you know there is an actual bug.

The inbound channel is expected to hold tasks in the queue. Exactly how many is too many depends on how the inbound channel thread pool is configured vs how many requests are coming in at a given time. If for example the thread pool allows only 2 threads, then any additional concurrent requests are queued. So this could be an in-flight number if there is a spike in requests.

The output shows that the number of CONNECT frames processed is much higher than the number of CONNECTED frames, 200 vs 132. That means 68 connect requests were either rejected explicitly or something happened that prevented a CONNECTED frame from being sent back. You need to do some logging and/or debugging to find out what causes that mismatch and whether it is perhaps related.

The output also indicates "2 transport error". This is again something that needs to be investigated through logging and/or debugging that could be related.

I'm closing for now but the issue can be reopened if you find there is an actual issue or if you manage to create an isolated sample to demonstrate the issue.