You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by He...@systema.com on 2025/10/13 14:03:06 UTC

Antwort: [Ext] Re: WebConsole on broker with many queues

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





Von:    "Ga?per ?efarin" <Ga...@actual-it.si>
An:     "users@activemq.apache.org" <us...@activemq.apache.org>
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 <mi...@gmail.com>
Sent: 08 October 2025 21:23:23
To: users@activemq.apache.org
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, <He...@systema.com>:

> 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
> Herbert.Helmstreit@systema.com
>
> 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.
>
>

Re: WebConsole on broker with many queues

Posted by Vilius Šumskas <vi...@rivile.lt.INVALID>.
Hi,

I can confirm what Herbert describes here. Using console on thousands of addresses and queues is very slow and, given large enough quantity, is unusable. We did experience OOMs in previous console version (the one which used old Hawtio 2.x). Performance on Hawtio 4.x series are better, and (I think) I never saw OOM with it, but it is still very slow with thousands of queues.

I was monitoring https://github.com/apache/activemq-artemis-console/pull/108 for a while, but it looks like it still didn’t make it into Artemis codebase. Though I’m eager to try again with latest Artemis console when it gets released.

--
    Vilius

From: Herbert.Helmstreit@systema.com <He...@systema.com>
Sent: Monday, October 13, 2025 5:03 PM
To: users@activemq.apache.org
Subject: Antwort: [Ext] Re: WebConsole on broker with many queues

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
Herbert.Helmstreit@systema.com<ma...@systema.com>

[cid:image001.png@01DC3C64.F30C2D90]

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:        "Gašper Čefarin" <Ga...@actual-it.si>>
An:        "users@activemq.apache.org<ma...@activemq.apache.org>" <us...@activemq.apache.org>>
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 <mi...@gmail.com>>
Sent: 08 October 2025 21:23:23
To: users@activemq.apache.org<ma...@activemq.apache.org>
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, <He...@systema.com>>:

> 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
> Herbert.Helmstreit@systema.com<ma...@systema.com>
>
> www.systema.com<http://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.
>
>

Antwort: [Ext] Re: Antwort: Re: Re: WebConsole on broker with many queues

Posted by He...@systema.com.
Thank You 
Herbert





Von:    "Justin Bertram" <jb...@apache.org>
An:     users@activemq.apache.org
Datum:  28.10.2025 15:37
Betreff:        [Ext] Re: Antwort: Re: Re: WebConsole on broker with many 
queues



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 <jb...@apache.org> 
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 <ta...@gmail.com> 
wrote:
>
>> On 10/14/25 02:55, Herbert.Helmstreit@systema.com 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
>> > Herbert.Helmstreit@systema.com
>> >
>> > 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" <jb...@apache.org>
>> > An: users@activemq.apache.org
>> > 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 <_Herbert.Helmstreit@systema.com_
>> > <ma...@systema.com>> 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*
>> > **Herbert.Helmstreit@systema.com* <mailto:
>> Herbert.Helmstreit@systema.com>
>> >
>> > *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" <_Gasper.Cefarin@actual-it.si_
>> > <ma...@actual-it.si>>
>> > An: "_users@activemq.apache.org_ <ma...@activemq.apache.org>"
>> > <_users@activemq.apache.org_ <ma...@activemq.apache.org>>
>> > 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 <_milovidoff@gmail.com_
>> > <ma...@gmail.com>>*
>> > Sent:* 08 October 2025 21:23:23*
>> > To:* _users@activemq.apache.org_ <ma...@activemq.apache.org>*
>> > 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, <_Herbert.Helmstreit@systema.com_
>> > <ma...@systema.com>>:
>> >
>> > > 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
>> > > _Herbert.Helmstreit@systema.com_ <mailto:
>> Herbert.Helmstreit@systema.com>
>> > >
>> > > _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: _users-unsubscribe@activemq.apache.org_
>> > <ma...@activemq.apache.org>
>> > For additional commands, e-mail: _users-help@activemq.apache.org_
>> > <ma...@activemq.apache.org>
>> > For further information, visit: _https://activemq.apache.org/contact_
>> > <https://activemq.apache.org/contact>
>> >
>> >
>>
>> --
>> Tim Bish
>>
>

Re: Antwort: [Ext] Re: Re: WebConsole on broker with many queues

Posted by Justin Bertram <jb...@apache.org>.
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 <jb...@apache.org> 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 <ta...@gmail.com> wrote:
>
>> On 10/14/25 02:55, Herbert.Helmstreit@systema.com 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
>> > Herbert.Helmstreit@systema.com
>> >
>> > 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" <jb...@apache.org>
>> > An: users@activemq.apache.org
>> > 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 <_Herbert.Helmstreit@systema.com_
>> > <ma...@systema.com>> 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*
>> > **Herbert.Helmstreit@systema.com* <mailto:
>> Herbert.Helmstreit@systema.com>
>> >
>> > *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" <_Gasper.Cefarin@actual-it.si_
>> > <ma...@actual-it.si>>
>> > An: "_users@activemq.apache.org_ <ma...@activemq.apache.org>"
>> > <_users@activemq.apache.org_ <ma...@activemq.apache.org>>
>> > 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 <_milovidoff@gmail.com_
>> > <ma...@gmail.com>>*
>> > Sent:* 08 October 2025 21:23:23*
>> > To:* _users@activemq.apache.org_ <ma...@activemq.apache.org>*
>> > 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, <_Herbert.Helmstreit@systema.com_
>> > <ma...@systema.com>>:
>> >
>> > > 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
>> > > _Herbert.Helmstreit@systema.com_ <mailto:
>> Herbert.Helmstreit@systema.com>
>> > >
>> > > _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: _users-unsubscribe@activemq.apache.org_
>> > <ma...@activemq.apache.org>
>> > For additional commands, e-mail: _users-help@activemq.apache.org_
>> > <ma...@activemq.apache.org>
>> > For further information, visit: _https://activemq.apache.org/contact_
>> > <https://activemq.apache.org/contact>
>> >
>> >
>>
>> --
>> Tim Bish
>>
>

Re: Antwort: [Ext] Re: Re: WebConsole on broker with many queues

Posted by Justin Bertram <jb...@apache.org>.
+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 <ta...@gmail.com> wrote:

> On 10/14/25 02:55, Herbert.Helmstreit@systema.com 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
> > Herbert.Helmstreit@systema.com
> >
> > 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" <jb...@apache.org>
> > An: users@activemq.apache.org
> > 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 <_Herbert.Helmstreit@systema.com_
> > <ma...@systema.com>> 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*
> > **Herbert.Helmstreit@systema.com* <mailto:Herbert.Helmstreit@systema.com
> >
> >
> > *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" <_Gasper.Cefarin@actual-it.si_
> > <ma...@actual-it.si>>
> > An: "_users@activemq.apache.org_ <ma...@activemq.apache.org>"
> > <_users@activemq.apache.org_ <ma...@activemq.apache.org>>
> > 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 <_milovidoff@gmail.com_
> > <ma...@gmail.com>>*
> > Sent:* 08 October 2025 21:23:23*
> > To:* _users@activemq.apache.org_ <ma...@activemq.apache.org>*
> > 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, <_Herbert.Helmstreit@systema.com_
> > <ma...@systema.com>>:
> >
> > > 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
> > > _Herbert.Helmstreit@systema.com_ <mailto:
> Herbert.Helmstreit@systema.com>
> > >
> > > _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: _users-unsubscribe@activemq.apache.org_
> > <ma...@activemq.apache.org>
> > For additional commands, e-mail: _users-help@activemq.apache.org_
> > <ma...@activemq.apache.org>
> > For further information, visit: _https://activemq.apache.org/contact_
> > <https://activemq.apache.org/contact>
> >
> >
>
> --
> Tim Bish
>

Re: Antwort: [Ext] Re: Re: WebConsole on broker with many queues

Posted by Timothy Bish <ta...@gmail.com>.
On 10/14/25 02:55, Herbert.Helmstreit@systema.com 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
> Herbert.Helmstreit@systema.com
>
> 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" <jb...@apache.org>
> An: users@activemq.apache.org
> 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 <_Herbert.Helmstreit@systema.com_ 
> <ma...@systema.com>> 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*
> **Herbert.Helmstreit@systema.com* <ma...@systema.com>
>
> *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" <_Gasper.Cefarin@actual-it.si_ 
> <ma...@actual-it.si>>
> An: "_users@activemq.apache.org_ <ma...@activemq.apache.org>" 
> <_users@activemq.apache.org_ <ma...@activemq.apache.org>>
> 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 <_milovidoff@gmail.com_ 
> <ma...@gmail.com>>*
> Sent:* 08 October 2025 21:23:23*
> To:* _users@activemq.apache.org_ <ma...@activemq.apache.org>*
> 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, <_Herbert.Helmstreit@systema.com_ 
> <ma...@systema.com>>:
>
> > 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
> > _Herbert.Helmstreit@systema.com_ <ma...@systema.com>
> >
> > _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: _users-unsubscribe@activemq.apache.org_ 
> <ma...@activemq.apache.org>
> For additional commands, e-mail: _users-help@activemq.apache.org_ 
> <ma...@activemq.apache.org>
> For further information, visit: _https://activemq.apache.org/contact_ 
> <https://activemq.apache.org/contact>
>
>

-- 
Tim Bish

Antwort: [Ext] Re: Re: WebConsole on broker with many queues

Posted by He...@systema.com.
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" <jb...@apache.org>
An:     users@activemq.apache.org
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 <He...@systema.com> 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
Herbert.Helmstreit@systema.com

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" <Ga...@actual-it.si> 
An:        "users@activemq.apache.org" <us...@activemq.apache.org> 
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 <mi...@gmail.com>
Sent: 08 October 2025 21:23:23
To: users@activemq.apache.org
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, <He...@systema.com>:

> 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
> Herbert.Helmstreit@systema.com
>
> 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: users-unsubscribe@activemq.apache.org
For additional commands, e-mail: users-help@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact

Re: [Ext] Re: WebConsole on broker with many queues

Posted by Justin Bertram <jb...@apache.org>.
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 <He...@systema.com> 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
> Herbert.Helmstreit@systema.com
>
> 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.
>
>
>
>
> Von:        "Gašper Čefarin" <Ga...@actual-it.si>
> An:        "users@activemq.apache.org" <us...@activemq.apache.org>
> 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 <mi...@gmail.com>
> * Sent:* 08 October 2025 21:23:23
> * To:* users@activemq.apache.org
> * 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, <He...@systema.com>:
>
> > 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
> > Herbert.Helmstreit@systema.com
> >
> > *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: users-unsubscribe@activemq.apache.org
> For additional commands, e-mail: users-help@activemq.apache.org
> For further information, visit: https://activemq.apache.org/contact
>