> ...do you think such amount of addresses/queues could be an issue for the broker itself?
It's only an issue if the broker doesn't have enough heap space to deal with them. There is no arbitrary limit to the number of addresses & queues a broker can have. The only limit is the inherent environmental constraints. > I mean it got me thinking, is running a queue per client an acceptable design? Again, that is an acceptable design assuming the broker has enough resources to deal with it. Without more details about your constraints I can't really say whether or not such a design is ultimately viable. > Can artemis-roles.properties file handle this amount of roles? I'm not sure what you mean exactly by "handle." Your question isn't specific enough. You've provided essentially zero information about your constraints. Application design is complicated with numerous constraints. You have physical constraints like disk space, CPU, and memory, performance constraints like latency and throughput, etc. A solution may be viable under one set of constraints but completely invalid under another set of constraints. Asking generic questions like this is like asking, "How long is a piece of string?" The answer is, "it depends." Aside from all this you may be interested in the "connection router" functionality [1] that is being finalized in 2.21.0. Instead of dividing clients up using thousands of queues on a single broker you could divide them up by queues on multiple brokers. Using the USER_NAME or ROLE_NAME key would let you reliably direct specific clients to specific brokers to avoid overloading a single broker. Justin [1] https://github.com/apache/activemq-artemis/blob/main/docs/user-manual/en/connection-routers.md On Tue, Mar 1, 2022 at 3:16 PM Vilius Šumskas <[email protected]> wrote: > Thank you for your reply. > > Yes, usually it's Java Heap Out Of Memory error which in turn crashes any > of the threads, be it Jolokia thread or any of the cluster connection > threads. > > I will try to increase memory limit and Prometheus is also on the horizon, > but in the meantime, do you think such amount of addresses/queues could be > an issue for the broker itself? I mean it got me thinking, is running a > queue per client an acceptable design? It was created to separate client > data, however we also have another related issue. Essentially we must > create thousands of roles and somehow map these roles to queues now. Can > artemis-roles.properties file handle this amount of roles? > > -- > Vilius > > -----Original Message----- > From: Justin Bertram <[email protected]> > Sent: Tuesday, March 1, 2022 10:49 PM > To: [email protected] > Subject: Re: ActiveMQ Artemis crashes with a lot of addresses/queues > > > Is this a known issue? > > I'm not sure I'd categorize this as a "known issue" as (in my opinion) > that implies it is a bug. I would simply say that you're reaching the > limits of the current design. The broker uses JMX for most management and > monitoring. > Most resources (e.g. the broker itself, addresses, queues, diverts, > bridges, acceptors, etc.) have a corresponding JMX MBean, and each of these > MBeans has individual attributes and operations. When a user first loads > the web console Hawtio requests all this information from the broker via > Jolokia. If you have a lot of addresses and queues this is a lot of MBeans > and therefore a lot of data that the broker has to collect and serialize > into JSON. Then Hawtio has to parse that JSON so it can build the interface > and populate the attributes, etc. The more MBeans you have the slower this > will be, of course. > > > Console is really slow and sometimes even crashes the broker. > > You don't really provide any details about exactly how/why the broker is > crashing so I can only assume that you're hitting an OutOfMemoryError. If > that's the case then I recommend you give your broker more memory in order > to deal with the overhead incurred for management. > > Aside from that you might consider using a metrics plugin [1] (e.g. the > Prometheus metrics plugin [2]) for monitoring instead of using the web > console. It doesn't use JMX at all and it only exports the metrics that are > relevant for monitoring rather than every single MBean attribute so > generally speaking the overhead is much lower. Also, you can turn metrics > on/off via the enable-metrics address-setting to reduce overhead even > further. > > > Justin > > [1] > > https://activemq.apache.org/components/artemis/documentation/latest/metrics.html > [2] https://github.com/jbertram/artemis-prometheus-metrics-plugin > > On Tue, Mar 1, 2022 at 1:51 PM Vilius Šumskas <[email protected]> > wrote: > > > Hi, > > > > we have Artemis 2.20.0 cluster which is used by external > > producers/consumers. Every such producer/consumer pair represents > > different commercial client (company) so we are using one queue per > > client to separate their messages. Our developers are using > > auto-created JMS address/queue combination to serve these clients. > > These auto-created queues are durable as per Artemis documentation. > > > > Now, the issue is we have thousands of these clients so naturally we > > have thousands of addresses and almost the same amount of queues in our > cluster. > > When trying to access Hawtio console the broker uses all CPU and RAM > > available. Console is really slow and sometimes even crashes the > > broker. Is this a known issue? > > > > This is on completely idle system with just couple of consumers > > attached at any given time (addresses are precreated in advance). The > > machines are multi-core Xeons with 8 GB of RAM. Address memory is barely > used ~12 MB. > > > > Or maybe we are doing something wrong? Maybe switching to temporary > > queues would help? > > > > -- > > Best Regards, > > > > Vilius Šumskas > > Rivile > > IT manager > > +370 614 75713 > > > > >
