ActiveMQ 5.18 to 5.19 Upgrade Guide, and When to Go to 6.x Instead

The short answer

Upgrade 5.18 brokers to the latest 5.19 release now, and decide on 6.x separately. Apache lists 5.18.x as Inactive, with 5.18.7 from 19 March 2025 as its last release, and only 5.19.x and 6.3.x as Active. 5.19 is built from 5.18 with additional features: it keeps the javax.jms broker API, the same Java 11 baseline, Spring 5.3 and Jetty 9.4, so for most estates the move is a binary swap and a configuration diff. It also closes CVE-2026-34197, the Jolokia code execution flaw fixed in 5.19.4 and 6.2.3 and never fixed on 5.18.

6.3 is a different size of job. It moves the broker and its client library to Jakarta Messaging and jakarta.jms, needs Java 17, and runs on Spring 7 and Jetty 12.1, so custom plugins, embedded brokers, web console customisations and client applications all have to move with it. Plan it as a project, ideally together with the application teams' own Jakarta migration.

The lines side by side

Versions are from Apache's ActiveMQ Classic download page. Apache defines Active lines as receiving regular community updates, including security patches, and Inactive lines as end of life with no further updates. 6.0, 6.1 and 6.2 are also Inactive, so a move to 6.x should go straight to 6.3. See ActiveMQ 5.18 end of life for the dates and the CVE detail.

Pre-upgrade checklist

• The exact version of every broker, and of the activemq-client or activemq-all jar inside every application.
• The JDK each broker runs on. 5.19 accepts the same Java 11 to 22 range as 5.18.
• Every file you changed under conf/: activemq.xml, jetty.xml, jetty-realm.properties, login.config, credentials.properties, log4j2.properties, and any Jolokia access policy.
• Custom broker plugins, interceptors or authentication modules built against ActiveMQ jars, and the Camel routes embedded in the broker.
• The KahaDB directory, its size, and the topology: standalone, shared-storage master/slave or network of brokers.
• A backup of the store taken the way Apache describes: freeze the filesystem holding KahaDB so the journal is consistent, then copy it. A copy taken with the broker stopped is simpler still.

# Broker version over Jolokia (5.x web console)
curl -s -u admin:admin \
  "http://localhost:8161/api/jolokia/read/org.apache.activemq:type=Broker,brokerName=localhost/BrokerVersion"

# Client library versions inside an application build
mvn dependency:tree | grep -E "org.apache.activemq:activemq-(client|all|broker|client-jakarta)"

Path 1: 5.18 to 5.19

Apache describes 5.19.0 as the first release of the 5.19 series, based on 5.18 with additional features. Its release notes list fixes and additions, including the ability to disable connector startup on boot and advanced message statistics on destinations, plus dependency updates. Apache's support table gives both lines the same JMS APIs, the same Java range and Spring 5.3.39, with Jetty moving only between 9.4 releases.

What to check anyway:

• Custom plugins. Rebuild them against the 5.19 jars and run their tests. Updated dependencies in the broker's lib/ directory are the usual source of surprises.
• Configuration drift. Diff your conf/ against the 5.18 defaults to see what you changed, then apply those changes to the 5.19 files rather than copying the old files over.
• Jolokia exposure. CVE-2026-34197 is reached through the Jolokia endpoint at /api/jolokia/ on the web console by an authenticated user. Upgrading closes it; also review who can log in to the console and whether it needs to be reachable at all.

diff -ru /opt/apache-activemq-5.18.7/conf /opt/apache-activemq-5.19.11/conf

Procedure for a standalone broker

# 1. Download and verify the release
gpg --import KEYS
gpg --verify apache-activemq-5.19.11-bin.tar.gz.asc apache-activemq-5.19.11-bin.tar.gz

# 2. Unpack next to the old version and carry over your configuration changes
tar xzf apache-activemq-5.19.11-bin.tar.gz -C /opt

# 3. Stop the old broker and copy the store
/opt/apache-activemq-5.18.7/bin/activemq stop
cp -a /var/lib/activemq/kahadb /backup/kahadb-5.18-$(date +%F)

# 4. Start 5.19 on the same data directory and check the log and version
/opt/apache-activemq-5.19.11/bin/activemq start
tail -f /opt/apache-activemq-5.19.11/data/activemq.log

Point the kahaDB directory attribute in activemq.xml, or the activemq.data setting, at the existing store, then watch the log for a clean recovery, check queue depths in the console against the numbers you recorded, and run a producer and consumer smoke test.

For shared-storage master/slave, upgrade the slave first, stop the master so the upgraded slave takes the lock, then upgrade the old master, which becomes the new slave. For a network of brokers, upgrade one broker at a time and watch the network connectors re-establish before moving on.

On Amazon MQ, 5.19 is the recommended engine version and 5.18 to 5.19 counts as a minor version upgrade, which you start as an engine version upgrade on the broker. autoMinorVersionUpgrade only moves a broker to the newest patch version. Amazon MQ does not offer ActiveMQ 6.x.

Path 2: 5.x to 6.3

Apache describes ActiveMQ 6 as modernising the 5.x broker engine for new JDK releases and Jakarta EE. The changes that need work:

• Java 17. 6.x requires JDK 17; 6.3 runs on Java 17 to 25.
• jakarta.jms in applications. The 6.x client uses jakarta.jms. Apache describes it as a package name change only: ActiveMQ's own package names and Spring bean definitions such as org.apache.activemq.ActiveMQConnectionFactory stay the same. The transitional activemq-client-jakarta module from 5.18 is removed in 6.x because it is no longer needed.
• Spring and Jetty on the broker. The broker configuration runs on Spring 7.0 in 6.3, and the web console on Jetty 12.1 instead of Jetty 9.4. Start from the jetty.xml shipped with 6.3 and reapply your changes, since a Jetty 9 file will not carry over.
• Embedded integrations. 6.x moved to Apache Camel 4 and Jolokia 2. Camel routes deployed inside the broker and anything that talks to Jolokia need retesting.
• Removed in 6.0. Solaris and 32-bit support, the 4.x-era JournalPersistenceAdapter, and the jetty-continuation and commons-collections dependencies, which plugins sometimes used without declaring them.
• Partial JMS 2.0. Methods that are not implemented yet throw UnsupportedOperationException. Apache's tracking table still lists delivery delay, async send with a CompletionListener and shared topic consumers as open. If an application plans to use them, Apache Artemis implements Jakarta Messaging 3.1 in full.

Find the code that has to change:

# Applications and plugins still on javax.jms
grep -rln "import javax\.jms\." src/

# JMS 2.0 features ActiveMQ 6 does not implement yet
grep -rnE "setDeliveryDelay|CompletionListener|createSharedConsumer|createSharedDurableConsumer" src/

# Persistence adapters removed in 6.0
grep -n "journalPersistenceAdapter\|JournalPersistenceAdapter" /opt/activemq/conf/activemq.xml

Order of work: move brokers to 5.19 first, so security fixes are not waiting on the Jakarta project. Then build each application against jakarta.jms with the 6.3 client, stand up a 6.3 broker in a test environment with your configuration ported to Spring 7 and Jetty 12.1, and test both your existing 5.x clients and the new 6.x clients against it before relying on a mixed estate. Apache's pages do not publish a client and broker compatibility matrix across major versions, so that test is the evidence.

KahaDB compatibility

Apache's KahaDB documentation says stores written by brokers newer than 5.9.0 will in many cases still be readable by a newer broker, which keeps using the store's older OpenWire version, and that stores created before 5.9.0 need storeOpenWireVersion="6" set by hand. It does not publish a statement for 5.18 to 5.19 or 6.x specifically. Treat it as something to prove: copy the production store, start the target version on the copy in a test environment, and compare destination counts and pending messages before the real change.

Rollback limits

Apache publishes no downgrade procedure for ActiveMQ Classic. The safe way back is the store copy taken with the old broker stopped: stop the new broker, put the old binaries and the copied store back, and start. Messages produced and acknowledged after the upgrade are not in that copy, so the longer the new version runs, the more a rollback costs. Starting old binaries on a store the new version has already written to is untested territory; do it only after a test on a copy. For 6.3 the application side matters too: keep the javax builds of client applications deployable until the brokers have settled.

Where OSSeva fits

When a broker cannot move to 5.19 straight away, often because a vendor product pins it or a change freeze is in force, OSSeva for ActiveMQ Classic backports security fixes to 5.15, 5.16, 5.17 and 5.18 as signed Maven, Docker and tarball builds, for the broker and the client libraries together. Apache maintains 5.19.x and 6.3.x, and OSSeva supports those lines beside the patched ones. OSSeva Assure adds a transport connector and authentication audit, a KahaDB store integrity review, a network-of-brokers topology review and an assessment of a move to Apache Artemis or RabbitMQ; OSSeva Operate executes that migration. Priced per broker cluster; book a discovery call for a quote. To compare the two brokers, read ActiveMQ Classic vs Artemis and the Classic to Artemis migration guide; for vendors, ActiveMQ support providers.

Frequently asked questions

Is ActiveMQ 5.18 end of life?

Yes. Apache lists 5.18.x as Inactive, which it defines as end of life with no further updates. 5.18.7, released on 19 March 2025, was the last release.

Is ActiveMQ 5.19 still supported?

Yes. Apache lists 5.19.x as Active alongside 6.3.x, and 5.19.11 is the latest release.

What Java version does ActiveMQ 5.19 need?

Java 11 or later; Apache's support table gives the range as Java 11 up to, but not including, 23. ActiveMQ 6.3 needs Java 17 to 25.

Does ActiveMQ 6 support javax.jms?

No. ActiveMQ 6 uses the jakarta.jms namespace for the broker and client. Applications still on javax.jms stay on the 5.19 line or move to jakarta.jms, which Apache describes as a package rename with no change to ActiveMQ's own class names.

Can I upgrade from ActiveMQ 5.18 directly to 6.3?

Nothing on Apache's pages requires a stop at 6.0, 6.1 or 6.2, all of which are Inactive. The work is in Java 17, Jakarta clients and porting the broker configuration, so most estates move to 5.19 first and treat 6.3 as a separate project.

Is CVE-2026-34197 fixed in ActiveMQ 5.18?

No. Apache fixed it in 5.19.4 and 6.2.3. Every 5.18 release is affected.

Does Amazon MQ support ActiveMQ 6?

No. Amazon MQ for ActiveMQ supports 5.19, which it recommends, and 5.18. Upgrading from 5.18 to 5.19 there is a minor version upgrade.