Category: Apache ActiveMQ®
Blog
Apache ActiveMQ 5.19.7 and 6.2.6
On May 27, the Apache ActiveMQ project shipped two releases on the same day: 5.19.7 and 6.2.6. Look at the changelogs side by side and the story is clear — this isn’t a feature drop. It’s a coordinated security-hardening pass applied to both maintained branches of ActiveMQ Classic at once, with the same fixes deliberately backported so that no supported line is left behind.
Blog
Upgrading to ActiveMQ 5.19.7 or 6.2.6
The latest Apache ActiveMQ releases – 5.19.7 and 6.2.6, both from May 27 – are good releases to apply. They close known dependency CVEs and tighten the broker’s default posture. (We covered the full list of changes in our release overview.) But here’s the catch with any “secure-by-default” update: hardening defaults means turning things off.
Blog
ActiveMQ Message Persistence: KahaDB, Artemis Journal & JDBC
Every persistent message in ActiveMQ must survive a broker restart. That guarantee is the contract behind DeliveryMode.PERSISTENT is what separates a messaging system from a memory buffer. It is also what makes message persistence configuration the most consequential decision in ActiveMQ architecture.
Blog
ActiveMQ on Kubernetes: Production Deployment Guide
Kubernetes is now the default deployment substrate for most enterprise platform teams. But ActiveMQ on Kubernetes presents a specific challenge that pure stateless workloads do not: message brokers are stateful.
Blog
ActiveMQ Monitoring & Alerting Setup: The Complete 2026 Guide
Most ActiveMQ outages are not sudden failures. They are visible in the metrics for minutes, sometimes hours, before they become incidents. A memory usage graph climbing past 60%. A queue depth that isn't draining. An enqueue time that doubled after a deployment. A consumer count that dropped from 3 to 1 at 2 AM.
Blog
ActiveMQ JMS 2.0 Implementation Guide: Simplified API, Transactions & Spring
For most of JMS's lifetime, writing a simple producer required creating a ConnectionFactory, creating a Connection, starting it, creating a Session, creating a MessageProducer, creating a Message, calling send(), and then closing the producer, session, and connection with the close calls safely wrapped in finally blocks to prevent resource leaks. Every developer knew the pattern. Every developer wrote it slightly differently. Every code review had the same comments about resource management.