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?
Regards Herbert 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]> 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 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] 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 P Please check whether a printout of this e-mail is really necessary. Von: "Gašper Čefarin" <[email protected]> An: "[email protected]" <[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]> Sent: 08 October 2025 21:23:23 To: [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]>: > 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] > > www.systema.com > > [image: LinkedIn] <https://www.linkedin.com/company/systema-gmbh/ >[image: > Facebook] <https://de-de.facebook.com/SYSTEMA.automation/>[image: 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. > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information, visit: https://activemq.apache.org/contact
