FYI - I've sent a PR for ARTEMIS-5427 [1] which should make a significant difference for high-load web console use-cases.
Justin [1] https://issues.apache.org/jira/browse/ARTEMIS-5427 On Tue, Oct 14, 2025 at 10:37 AM Justin Bertram <[email protected]> wrote: > +1 to GitHub. > > To be clear, an out-of-band upload is much preferred to attachments. > There's no need to distribute copies of an attached reproducer to over > 1,000 individual inboxes. > > > Justin > > On Tue, Oct 14, 2025 at 9:15 AM Timothy Bish <[email protected]> wrote: > >> On 10/14/25 02:55, [email protected] wrote: >> > Hello Justin, >> > >> > I had attached the Program to the previous email, but it was stripped >> > when it got posted. >> > What would be the right place to put it? >> >> One easy way to share is to create a public Github repository with your >> reproducer and share the link here. >> >> >> > >> > >> > Regards >> > >> > Herbert >> > >> > ------------------------------------------------------------------------ >> > >> > *Herbert Helmstreit* >> > Senior Software Engineer >> > >> > Phone: +49 941 / 7 83 92 36 >> > [email protected] >> > >> > www.systema.com <https://www.systema.com/> >> > >> > LinkedIn <https://www.linkedin.com/company/systema-gmbh/>Facebook >> > <https://de-de.facebook.com/SYSTEMA.automation/>XING >> > <https://www.xing.com/pages/systemagmbh> >> > >> > SYSTEMA >> > Systementwicklung Dipl.-Inf. Manfred Austen GmbH >> > >> > Manfred-von-Ardenne-Ring 6 | 01099 Dresden >> > HRB 11256 Amtsgericht Dresden | USt.-ID DE 159 607 786 >> > Geschäftsführer: Manfred Austen, Enno Danke, Dr. Ulf Martin, Jürg >> Matweber >> > >> > P Please check whether a printout of this e-mail is really necessary. >> > >> > >> > >> > >> > >> > Von: "Justin Bertram" <[email protected]> >> > An: [email protected] >> > Datum: 13.10.2025 20:47 >> > Betreff: [Ext] Re: Re: WebConsole on broker with many queues >> > ------------------------------------------------------------------------ >> > >> > >> > >> > I just set up a quick proof-of-concept using a new, default instance >> > of 2.42.0 with 18,000 multicast addresses with no queues defined in >> > broker.xml. I set up a producer and consumer to run constantly in the >> > background sending and receiving messages as fast as possible, and >> > then I opened the web console and browsed through the addresses. >> > Memory spiked up to 800MB when I first logged in to the web console, >> > but everything seemed to work fine. There was no significant >> > lag/slow-down. >> > >> > Could you perhaps upload your MultiQueue.java somewhere so I could >> > reproduce what you're seeing? Clearly my proof-of-concept didn't cover >> > your specific use-case. >> > >> > >> > Justin >> > >> > On Mon, Oct 13, 2025 at 9:04 AM <[email protected]_ >> > <mailto:[email protected]>> wrote: >> > Hello Gašper, >> > >> > 1000 queues are not enough to hit the session TTL. >> > It has been reported, that Webconsole does not open, if the number of >> > objects (Queues, Topics) is too big. >> > Customer had 18000 Adress objects and opening WebConsole made all >> > Clients to connect to another broker in the cluster. >> > >> > The program MultiQueue.java creates a given number of _queues.to_ >> > <http://queues.to/>simulate it. >> > >> > >> > Start it with 3 args >> > 0: connectionurl >> > 1: Prefix e.g. MultiQ >> > 2: 18000 >> > It will connect to connectionurl and try to create MultiQ_0 ... >> > MultiQ_17999 >> > When MultiQ_16000 or so is created, try and open WebConsole: >> > After login it is completetly knocked-out and seems to bring the >> > broker to the limit. >> > After some time the test program terminates: >> > >> > serving on:ActiveMQQueue[MultiQ_16111] >> > 256 ||| slf4j ||| RemotingConnectionID=5b5b386c Sending blocking >> > SessionQueueQueryMessage[type=45, channelID=11, responseAsync=false, >> > requiresResponse=false, correlationID=-1, queueName=MultiQ_*16112*] >> > 256 ||| slf4j ||| RemotingConnectionID=5b5b386c handling packet >> > SessionQueueQueryResponseMessage_V3[type=-14, channelID=11, >> > responseAsync=false, requiresResponse=false, correlationID=-1, >> > address=MultiQ_16112, name=MultiQ_16112, consumerCount=0, >> > filterString=null, durable=true, exists=false, temporary=false, >> > messageCount=0, autoCreationEnabled=true, autoCreated=false, >> > purgeOnNoConsumers=false, routingType=MULTICAST, maxConsumers=-1, >> > exclusive=false, groupRebalance=false, >> > groupRebalancePauseDispatch=false, groupBuckets=-1, >> > groupFirstKey=null, lastValue=false, lastValueKey=null, >> > nonDestructive=false, consumersBeforeDispatch=0, >> > delayBeforeDispatch=-1, autoDelete=false, autoDeleteDelay=0, >> > autoDeleteMessageCount=0, defaultConsumerWindowSize=1048576, >> > ringSize=-1, enabled=null, configurationManaged=false] >> > 256 ||| slf4j ||| RemotingConnectionID=5b5b386c Sending blocking >> > SessionBindingQueryMessage[type=49, channelID=11, responseAsync=false, >> > requiresResponse=false, correlationID=-1, address=MultiQ_16112]] >> > 256 ||| slf4j ||| RemotingConnectionID=5b5b386c handling packet >> > SessionBindingQueryResponseMessage_V5[type=-22, channelID=11, >> > responseAsync=false, requiresResponse=false, correlationID=-1, >> > exists=false, queueNames=[], autoCreateQueues=true, >> > autoCreateAddresses=true, defaultPurgeOnNoConsumers=false, >> > defaultMaxConsumers=-1, defaultExclusive=false, >> > defaultLastValue=false, defaultLastValueKey=null, >> > defaultNonDestructive=false, defaultConsumersBeforeDispatch=0, >> > defaultDelayBeforeDispatch=-1, supportsMulticast=false, >> > supportsAnycast=false] >> > 256 ||| slf4j ||| RemotingConnectionID=5b5b386c Sending blocking >> > CreateQueueMessage_V2[type=-12, channelID=11, responseAsync=false, >> > requiresResponse=true, correlationID=-1, address=MultiQ_16112, >> > queueName=MultiQ_16112, filterString=null, durable=true, >> > temporary=false, autoCreated=true, routingType=ANYCAST, >> > maxConsumers=-1, purgeOnNoConsumers=false, exclusive=null, >> > groupRebalance=null, groupRebalancePauseDispatch=null, >> > groupBuckets=null, groupFirstKey=null, lastValue=null, >> > lastValueKey=null, nonDestructive=null, consumersBeforeDispatch=null, >> > delayBeforeDispatch=null, autoDelete=null, autoDeleteDelay=null, >> > autoDeleteMessageCount=null, ringSize=null, enabled=null] >> > 256 ||| slf4j ||| RemotingConnectionID=5b5b386c Sending packet >> > nonblocking Ping[type=10, channelID=0, responseAsync=false, >> > requiresResponse=false, correlationID=-1, connectionTTL=60000] on >> > channelID=0 >> > 256 ||| slf4j ||| RemotingConnectionID=5b5b386c Writing buffer for >> > channelID=0 >> > 256 ||| slf4j ||| RemotingConnectionID=5b5b386c handling packet >> > Ping[type=10, channelID=0, responseAsync=false, >> > requiresResponse=false, correlationID=-1, connectionTTL=60000] >> > Exception in thread "main" javax.jms.JMSException: AMQ219014: Timed >> > out after waiting 30000 ms for response when sending packet -12 >> > at >> > >> org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:570) >> > at >> > >> org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:464) >> > at >> > >> org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:456) >> > at >> > >> org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.createQueue(ActiveMQSessionContext.java:856) >> > at >> > >> org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.internalCreateQueue(ClientSessionImpl.java:1953) >> > at >> > >> org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.createQueue(ClientSessionImpl.java:326) >> > at >> > >> org.apache.activemq.artemis.utils.AutoCreateUtil.autoCreateQueue(AutoCreateUtil.java:57) >> > at >> > >> org.apache.activemq.artemis.jms.client.ActiveMQSession.createConsumer(ActiveMQSession.java:917) >> > at >> > >> org.apache.activemq.artemis.jms.client.ActiveMQSession.createConsumer(ActiveMQSession.java:563) >> > at >> > >> org.apache.activemq.artemis.jms.client.ActiveMQSession.createConsumer(ActiveMQSession.java:529) >> > at MultiQueue.subscribeToQ(MultiQueue.java:132) >> > at MultiQueue.main(MultiQueue.java:158) >> > Caused by: >> > >> org.apache.activemq.artemis.api.core.ActiveMQConnectionTimedOutException:[errorType=CONNECTION_TIMEDOUT >> >> > message=AMQ219014: Timed out after waiting 30000 ms for response when >> > sending packet -12] >> > ... 12 more >> > >> > The number *16112* we reached is depending from a lot of things like >> > timing of the WebConsole opening. >> > As said before the OOM was probably a side effect caused by something >> > else. >> > The broker has 4G of memory and runs just fine in other cases. >> > Is there a nightly build of the broker, I would be curious to test it. >> > >> > Best Regards >> > >> > Herbert >> > >> > ------------------------------------------------------------------------ >> > >> > *Herbert Helmstreit* >> > Senior Software Engineer >> > Phone: +49 941 / 7 83 92 36* >> > **[email protected]* <mailto: >> [email protected]> >> > >> > *www.systema.com* <https://www.systema.com/> >> > >> > SYSTEMA >> > Systementwicklung Dipl.-Inf. Manfred Austen GmbH >> > Manfred-von-Ardenne-Ring 6 | 01099 Dresden >> > HRB 11256 Amtsgericht Dresden | USt.-ID DE 159 607 786 >> > Geschäftsführer: Manfred Austen, Enno Danke, Dr. Ulf Martin, Jürg >> > Matweber >> > PPlease check whether a printout of this e-mail is really necessary. >> > >> > >> > >> > >> > Von: "Gašper Čefarin" <[email protected]_ >> > <mailto:[email protected]>> >> > An: "[email protected]_ <mailto:[email protected]>" >> > <[email protected]_ <mailto:[email protected]>> >> > Datum: 09.10.2025 14:19 >> > Betreff: [Ext] Re: WebConsole on broker with many queues >> > ------------------------------------------------------------------------ >> > >> > I cannot reproduce the issue with 1000 queues but no >> > messages/consumers/producers. >> > >> > There was a big load produced on the broker when the web console was >> > gathering into for permissions for every queue - this (and slow >> > rendering of many queues) is now fixed in the current version - which >> > is not yet released. >> > I'm not sure it could cause OOM though. >> > >> > Answers to the questions asked by Justin would help to pinpoint the >> > issue a lot. >> > I would also ask how many consumers/producers there were online. >> > >> > >> > >> > >> > ------------------------------------------------------------------------ >> > * >> > From:* Alexander Milovidov <[email protected]_ >> > <mailto:[email protected]>>* >> > Sent:* 08 October 2025 21:23:23* >> > To:* [email protected]_ <mailto:[email protected]>* >> > Subject:* Re: WebConsole on broker with many queues >> > >> > >> > To sporočilo izvira izven naše organizacije. Bodite pozorni pri >> > vsebini in odpiranju povezav ali prilog. >> > >> > >> > >> > >> > I also had a similar issue with performance of Artemis 2.40.0 web >> console >> > with about 3000 addresses/queues, but had not much time to investigate >> the >> > issue, gather thread dumps, create a reproducer etc. >> > And we still did not try to migrate any of Artemis instances to 2.40+ >> > (even >> > smaller ones). >> > >> > пн, 6 окт. 2025 г. в 17:00, <[email protected]_ >> > <mailto:[email protected]>>: >> > >> > > Hello Team, >> > > >> > > on an Artemis broker 2.42 with some thousands of queues and topics >> > we can >> > > reproduce the >> > > following case: >> > > open a WebConsole. >> > > >> > > - broker blocked, browser frozen >> > > - 100% CPU for broker process >> > > - This situation lasts longer as the client session keep alive >> period >> > > (30 sec). Therefore clients terminate the connections. >> > > - additional tasks cleaning up all objects. >> > > >> > > We had a single case, where the broker completely crashed with OOM >> > in such >> > > a situation. >> > > But in most cases the broker survives with all clients gone to another >> > > broker by desaster failover. >> > > Should we avoid WebConsole at all or is there a switch to keep this >> load >> > > out of the broker? >> > > >> > > Best Regards >> > > >> > > Herbert >> > > ------------------------------ >> > > >> > > *Herbert Helmstreit* >> > > Senior Software Engineer >> > > >> > > Phone: +49 941 / 7 83 92 36 >> > > [email protected]_ <mailto: >> [email protected]> >> > > >> > > _www.systema.com_ <http://www.systema.com/> >> > > >> > > [image: LinkedIn] <_https://www.linkedin.com/company/systema-gmbh/_ >> > <https://www.linkedin.com/company/systema-gmbh/>>[image: >> > > Facebook] <_https://de-de.facebook.com/SYSTEMA.automation/_ >> > <https://de-de.facebook.com/SYSTEMA.automation/>>[image: XING] >> > > <_https://www.xing.com/pages/systemagmbh_ >> > <https://www.xing.com/pages/systemagmbh>> >> > > >> > > SYSTEMA >> > > Systementwicklung Dipl.-Inf. Manfred Austen GmbH >> > > >> > > Manfred-von-Ardenne-Ring 6 | 01099 Dresden >> > > HRB 11256 Amtsgericht Dresden | USt.-ID DE 159 607 786 >> > > Geschäftsführer: Manfred Austen, Enno Danke, Dr. Ulf Martin, Jürg >> > Matweber >> > > >> > > P Please check whether a printout of this e-mail is really necessary. >> > > >> > > >> > >> > >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [email protected]_ >> > <mailto:[email protected]> >> > For additional commands, e-mail: [email protected]_ >> > <mailto:[email protected]> >> > For further information, visit: _https://activemq.apache.org/contact_ >> > <https://activemq.apache.org/contact> >> > >> > >> >> -- >> Tim Bish >> >
