Is ActiveMQ + Spring STOMP good for scaling websockets, or should we look towards something else?

We have a Spring Boot backend which also maintains bidirectional (STOMP over) websocket connections with clients (browser tabs). We've implemented this using STOMP Broker Relay (server side) + ActiveMQ (message broker). There's also a heartbeat message exchanged every 25s to keep connections alive.

Problem we are facing

Till about 1K connections, this setup seems to work fine. Once it goes beyond few thousand connections in ActiveMQ, we are running into some weird issues: browser is able to successfully connect and subscribe to a topic on ActiveMQ through Spring Boot, however no messages are successfully received by it, all while being able to exchange heartbeats every 25s! Our Spring Backend has increased CPU utilization where there is one thread tcp-client-loop that consumes 1 full CPU.

We have also shared our complete investigation below.

Question

Is this architecture with some tunables, a good solution for scaling up to ~100k concurrent websocket connections tomorrow? If not, what are some industry recommended alternatives for sending notifications to a browser? We've also been looking at socket.io + redis pub/sub for the huge amount of references on the internet but unsure if it's actually a better approach.

Investigation so far

1. Our backend logs show that events are being published and relayed to the client, however these events have an empty payload and contain stompMessageType as OTHER instead of the supposed value MESSAGE. We have also used a stomp client on the terminal to connect with ActiveMQ directly and noticed no messages coming in from subscribed topics during this period, so this has turned our attention towards something wrong on the ActiveMQ broker side.
2. During this same high traffic time period, we've noticed our backend being stuck in a tcp-client-loop thread, however haven't been able to pinpoint if this is related to connections with the ActiveMQ server or not. P.S. - we have decided to rule out the tcp connection limit during high traffic due to connections being established successfully. We've also configured ActiveMQ to accept 50k connections over STOMP instead of the default 1k.
3. There's little to nothing we have been able to find out from ActiveMQ's logs (and web console) for errors around publishing or consuming, even at the DEBUG and TRACE log levels. CPU utilisation hovers around just 5% during this time.