Should I worry about large numbers of stomp-subscription queues?

218 views
Skip to first unread message

Brad Wood

unread,
Jan 5, 2021, 9:30:55 PM1/5/21
to rabbitm...@googlegroups.com
Using RabbitMQ 3.8.9 with stomp and web stomp plugins.  When I use a Stomp.js library (like this one) to create web socket topic subscriptions from the browser, there is a queue called "stomp-subscription--<random string>" created for each topic I subscribe to.

So some code in the browser like this:

 stompClient.subscribe('/topic/topic1', function (message) {});
 stompClient.subscribe('/topic/topic2', function (message) {});
 stompClient.subscribe('/topic/topic3', function (message) {});
 stompClient.subscribe('/topic/topic4', function (message) {});
 stompClient.subscribe('/topic/topic5', function (message) {});

creates 5 queues and 5 bindings to the amq.topic exchange in Rabbit.  There is still only a single channel and a single Connection.  Ok, no problem.  

Now, if I open a second browser window the numbers double and I have 10 queues and 10 bindings.  What concerns me is I'm planning to use this for an app with perhaps 2000 users online at once, but I expect to have 20-30 topics that each user/browser will be subscribed to.  Some quick math shows I'll be looking at 40,000 to 60,000 queues/bindings to support this!

I've spent about two days googling around and there just isn't any information online that says whether I need to be concerned about this.  Here's some of the posts I've read on the topic:

I'm new to web stomp via Rabbit so I'm also wondering if I'm doing something wrong.  The only real conversation I could find (second link above) on Google in this list related to max queues sort of said that the number of connections would be an issue-- but in my case that doesn't really apply since I don't plan on having many actual TCP connections.  

I did find the x-queue-name header (4th link above) which allows me to control what queue the subscription uses.  

 stompClient.subscribe('/topic/topic5', function (message) {}, {"x-queue-name":"my-queue"});

This seemed promising at first, but then I realized that when I have two browsers making this same topic subscription and using the same x-queue-name, only one of the browsers gets any messages sent to that topic.  So that idea is either not what I'm looking for, or I'm doing it wrong.  It would appear, even if I choose the name, I still must have a unique queue name per connection/topic subscription.

I probably only have around 6,000 actual unique topics in this app.  Is there a way to not deal with the ballooning issues of the "stomp-subscription--<random string>" queues, or is this no issue at all and I can just keep along my current plan and stop worrying about it?

Thanks!

~Brad

Developer Advocate
Ortus Solutions, Corp 

ColdBox Platform: http://www.coldbox.org 

Brad Wood

unread,
Jan 13, 2021, 2:30:22 PM1/13/21
to rabbitm...@googlegroups.com
I waited over a week to bump this time.  Any input here on the number of stomp queues and usage of x-queue-name?

Thanks!

~Brad

Developer Advocate
Ortus Solutions, Corp 

ColdBox Platform: http://www.coldbox.org 


Reply all
Reply to author
Forward
0 new messages