RabbitMQ STOMP over WebSockets - single queue for multiple SUBSCRIBES

[Filip Maretić]

Following the guide at https://www.rabbitmq.com/stomp.html I was able to setup a broker that would deliver messages to browsers via WebSockets while communicating with the STOMP protocol.

In one of the productions setups there can be around 800 clients maximum. Each client could be interested in lets say around 50 types of events out of 200 available at any moment. These events are published to an direct exchange each with a routing key (event ID). 

In this scenario following the guide the first version would be for each client to send a SUBSCRIBE frame specifying the exchange directly in the destination header e.g, /exchange/events/123 where 123 is the event ID. Using this approach this would generate 800 * 50 = 40 000 queues on RabbitMQ. This adds a lot of overhead since the clients can loose connections thus recreating queues all the time which puts pressure on RabbitMQ.

Luckily there is the option to specify the x-queue-name header which can create a stable queue name and do nothing if it already exists. The second version of the system was made where a Spring Boot (Java framework) was added as a relay between the clients and RabbitMQ. The Spring app now identifies the client and its WebSocket session and creates a single queue for each client no matter how many SUBSCRIBE frames it sends. Now instead of 40 000 queues we have 800 queues and each queue has multiple bindings on the /exchange/events exchange (in this case 50 bindings).

But, now there is an issue with this setup. Inspecting the STOMP messages send from the server to the client I observed that the destination IDs and consumer tags do not exactly match as expected. It seems they get randomly selected by the broker from the pool of consumers and sent back to client. This is not a big issue when the queue is bound to the same exchange but things get messy if multiple exchanges are used.

Does anybody have any experience with this and maybe knows what could be the issue? Is it really the case we need to have a dedicated queue for each SUBSCRIBE frame?

Thanks