Classified as: {Hitachi Rail – Public}
Hi Jean,
Yes I thought exactly the same, very strange. I realised we were using camel
for some queues but I've stripped that out to simplify the xml file - but it
made no difference to the problem. Here's the activemq.xml
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with
the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<!-- START SNIPPET: example -->
<beans xmlns="http://www.springframework.org/schema/beans";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://activemq.apache.org/schema/core
http://activemq.apache.org/schema/core/activemq-core.xsd";>
<!-- Allows us to use system properties as variables in this configuration
file -->
<bean
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="locations">
<list>
<value>file:${activemq.conf}/credentials.properties</value>
<value>file:${activemq.conf}/darwin.properties</value>
</list>
</property>
</bean>
<!-- we are using a pluggable locker so set the correct exception handler -->
<bean id="ioExceptionHandler"
class="org.apache.activemq.util.LeaseLockerIOExceptionHandler"> </bean>
<!--
The <broker> element is used to configure the ActiveMQ broker.
-->
<broker xmlns="http://activemq.apache.org/schema/core"; brokerName="localhost"
dataDirectory="${activemq.data}">
<destinationPolicy>
<policyMap>
<policyEntries>
<policyEntry topic=">">
<!-- The constantPendingMessageLimitStrategy is used to prevent
slow topic consumers to block producers and affect
other consumers
by limiting the number of messages that are retained
For more information, see:
http://activemq.apache.org/slow-consumer-handling.html
-->
<pendingMessageLimitStrategy>
<constantPendingMessageLimitStrategy limit="1000"/>
</pendingMessageLimitStrategy>
</policyEntry>
</policyEntries>
</policyMap>
</destinationPolicy>
<!--
The managementContext is used to configure how ActiveMQ is exposed
in
JMX. By default, ActiveMQ uses the MBean server that is started by
the JVM. For more information, see:
http://activemq.apache.org/jmx.html
-->
<managementContext>
<managementContext createConnector="false"/>
</managementContext>
<!--
Configure message persistence for the broker. The default
persistence
mechanism is the KahaDB store (identified by the kahaDB tag).
For more information, see:
http://activemq.apache.org/persistence.html
-->
<persistenceAdapter>
<!-- <kahaDB directory="${activemq.data}/kahadb"/> -->
<kahaDB directory="/data/kahadb"/>
</persistenceAdapter>
<!--
The systemUsage controls the maximum amount of space the broker will
use before disabling caching and/or slowing down producers. For
more information, see:
http://activemq.apache.org/producer-flow-control.html
-->
<systemUsage>
<systemUsage>
<memoryUsage>
<memoryUsage percentOfJvmHeap="70"/>
</memoryUsage>
<storeUsage>
<storeUsage limit="100 gb"/>
</storeUsage>
<tempUsage>
<tempUsage limit="50 gb"/>
</tempUsage>
</systemUsage>
</systemUsage>
<!--
The transport connectors expose ActiveMQ over a given protocol to
clients and other brokers. For more information, see:
http://activemq.apache.org/configuring-transports.html
-->
<transportConnectors>
<!-- DOS protection, limit concurrent connections to 1000 and frame size to
100MB -->
<transportConnector name="openwire"
uri="tcp://0.0.0.0:61616?maximumConnections=1000&wireFormat.maxFrameSize=104857600"/>
<!--
<transportConnector name="amqp"
uri="amqp://0.0.0.0:5672?maximumConnections=1000&wireFormat.maxFrameSize=104857600"/>
<transportConnector name="stomp"
uri="stomp://0.0.0.0:61613?maximumConnections=1000&wireFormat.maxFrameSize=104857600"/>
<transportConnector name="mqtt"
uri="mqtt://0.0.0.0:1883?maximumConnections=1000&wireFormat.maxFrameSize=104857600"/>
<transportConnector name="ws"
uri="ws://0.0.0.0:61614?maximumConnections=1000&wireFormat.maxFrameSize=104857600"/>
-->
</transportConnectors>
<!-- destroy the spring context on shutdown to stop jetty -->
<shutdownHooks>
<bean xmlns="http://www.springframework.org/schema/beans";
class="org.apache.activemq.hooks.SpringContextHook"/>
</shutdownHooks>
</broker>
<!--
Enable web consoles, REST and Ajax APIs and demos
The web consoles requires by default login, you can disable this in the
jetty.xml file
Take a look at ${ACTIVEMQ_HOME}/conf/jetty.xml for more details
-->
<import resource="jetty.xml"/>
</beans>
Regards
Rob
{Hitachi Rail – Public}
-----Original Message-----
From: Jean-Baptiste Onofré <[email protected]>
Sent: 12 February 2026 08:58
To: [email protected]
Cc: KIRKBRIDE Robert <[email protected]>
Subject: Re: ActiveMQ Classic Linux Broker Performance Issues
[You don't often get email from [email protected]. Learn why this is important
at https://aka.ms/LearnAboutSenderIdentification ]
Hmm, I'm a bit surprised because I would expect the opposite between Windows
and Unix :)
Can you share the activemq.xml you are using?
Regards
JB
On Wed, Feb 11, 2026 at 7:33 PM Rob Kirkbride <[email protected]>
wrote:
> Yes the same in both cases I believe.
> We are in an Aws environment so we've tried both Amazon Linux and
> Ubuntu Linux and applied all available patches.
> We've also tried increasing the iops on the SSD storage, though
> there's no evidence that it's a bottleneck.
>
> On Wed, 11 Feb 2026, 18:27 Jean-Baptiste Onofré, <[email protected]> wrote:
>
> > Hi
> >
> > Are you using the same activemq.xml ? Same JVM configuration ?
> >
> > We would need more details to investigate.
> >
> > Regards
> > JB
> >
> > On Wed, Feb 11, 2026 at 6:02 PM KIRKBRIDE Robert via users <
> > [email protected]> wrote:
> >
> > > Classified as: {Hitachi Rail - Public}
> > >
> > > We seem to have hit an issue with Linux Broker vs Windows Broker
> > > performance that we can't understand or resolve.
> > > We are using v6.2.0 of ActiveMQ Classic. We have a service that is
> > pushing
> > > messages to a virtual topic (VirtualTopic.Name), typically around
> > > 20-30 bytes and these are being published at a frequency of around
> > > 130
> > messages /
> > > second. We then have two services consuming from separate virtual
> > > topic queues (Consumer.service.VirtualTopic.Name). On a Windows
> > > broker we
> are
> > > seeing ActiveMQ easily deal with this, with low CPU and memory usage.
> > With
> > > a Linux broker the messages are being consumed but seemingly not
> > > fast enough as the queues build up over time (probably running
> > > about half
> the
> > > speed required)
> > > The specifications of the Linux and Windows VMs are the same and
> > > in
> both
> > > cases, memory and CPU is low.
> > > The clients are C# .NET services. Nothing else about the
> > > environment changes. Any ideas as how we can resolve this,
> > > anything to try? Thanks
> a
> > > lot in advance.
> > >
> > >
> > > {Hitachi Rail - Public}
> > >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information, visit: https://activemq.apache.org/contact
