Category: Messaging
Blog
10 Questions to Ask an Apache ActiveMQ® Support Vendor
Deciding to buy open source support for Apache ActiveMQ® is the easy part. Working out which vendor can actually keep a broker alive at three in the morning is considerably harder, because nearly every vendor in this market is vague in exactly the same places.
Blog
Apache ActiveMQ® CVE-2023-46604: DripDropper Exploit Explained
When a CVSS 10.0 vulnerability is published, the expectation is that affected software gets patched within days. When it involves an open-source broker that processes business-critical transactions in enterprise environments, the expectation is that the security teams responsible for those brokers treat it as an emergency. “The attacks exploit a maximum-severity security flaw in Apache
Blog
Apache ActiveMQ® CVE Guide: Complete Vulnerability Reference
This Apache ActiveMQ® CVE guide is the maintained reference for every significant Apache ActiveMQ® vulnerability: what it does, how it is scored, which versions it affects, which release fixes it, and whether it is being exploited.
Blog
The Future of Enterprise Messaging: What 2026–2030 Holds
Enterprise messaging is not a solved problem sitting still. The last five years have reshaped the technology landscape in ways that are still working their way through enterprise architecture decisions: Kafka's dominance in event streaming, the rise of cloud-native managed messaging (Amazon MQ, Azure Service Bus, Confluent Cloud), the democratization of the Kafka protocol across competing implementations, and now the early emergence of agentic AI as a new category of messaging consumer.
Blog
Apache ActiveMQ® End of Life: What Enterprises Need to Know
If you have searched for Apache ActiveMQ® end of life, you have probably encountered a wall of conflicting answers: some claiming the broker is dead, others insisting it is fine forever. Both are wrong.
Blog
Apache ActiveMQ Zero-Downtime Maintenance: The Complete Procedures Guide
The broker is processing 8,000 messages per second. There are 340 active client connections. A configuration change is needed: a memoryUsage limit increase to prevent an approaching producer flow control event. The question is not whether to make the change. The question is how to make it without dropping messages, disconnecting clients, or triggering a cascade of client reconnect storms that themselves cause the resource pressure you are trying to resolve.