The broker itself doesn't impose any arbitrary limits on the number of addresses & queues. That said, there certainly are limits, the size of your heap probably being the most important. Every address and queue carry with it some memory overhead including the objects themselves but also related objects like JMX MBeans which enable management.
The current management console will struggle by default with a huge number of addresses and/or queues due to the way the "tree" view works (i.e. refreshing the whole view on a regular basis). This is the main reason we removed this view in the new console [1]. That said, the console can be configured in such a way as to mitigate some of these problems. I can provide more details on that if necessary although it's been covered on this list a few times already. Regarding scalability...the broker was written with scalability in mind, but everything breaks down at some point. I'm interested to hear about your experiences if you go down this route especially regarding bottlenecks that you may find for your specific use-case. Keep us in the loop! Justin [1] https://issues.apache.org/jira/browse/ARTEMIS-5319 On Wed, Mar 5, 2025 at 12:33 PM William Crowell <wcrow...@perforce.com.invalid> wrote: > Good afternoon, > > Are there any limitations or concerns with creating millions of topics and > queues within Apache Artemis that have low volumes of messages in each > topic and queue? I do not think there are as I believe Artemis should be > able to handle this use case. Important question is: Is it scalable? > > Regards and have a great day, > > William Crowell > > > This e-mail may contain information that is privileged or confidential. If > you are not the intended recipient, please delete the e-mail and any > attachments and notify us immediately. > >
