Category: Monitoring
Blog
Troubleshooting ActiveMQ Producer Flow Control Blocks
The alert comes in at 2 AM: your order processing service is unresponsive. The application is not crashed, threads are running, the JVM is healthy, but no messages are being sent. Your operations team traces it to a blocked send() call on an ActiveMQ connection. Hours later, after restarting the application, someone finds this line in the broker log from 11 PM the previous day:
Blog
ActiveMQ Protocol Comparison: AMQP vs MQTT vs OpenWire vs STOMP
One of ActiveMQ's most powerful and underappreciated capabilities is its protocol polyglotism: a single broker can simultaneously accept Java JMS clients over OpenWire, Python services over AMQP, IoT sensors over MQTT, and Ruby scripts over STOMP, all routing messages between each other without protocol bridges or translation middleware.
Blog
The Silent Killer of IBM MQ®: How One Leaky App Can Crash Your Entire Estate
A single leaky application can crash your entire IBM MQ® estate by consuming OS resources through unclosed connections. Traditional monitoring misses these silent killers. Learn how proactive observability detects OPPROCS anomalies before they trigger infrastructure failures.
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 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.