Apache ActiveMQ Glossary
Your essential reference guide to the language of enterprise messaging — 48 terms spanning core concepts, architecture, persistence, operations, and advanced features.
Core Terminology
Message Broker
A middleware component that serves as the central hub for message exchange between applications. The broker receives messages from producers, stores them appropriately, and delivers them to the designated consumers. Think of it as the intelligent routing engine powering your distributed application communication layer. At its core, messaging is a popular technology for providing reliable event-driven communication between computer systems, and the broker sits at the heart of this communication, ensuring messages flow reliably between disparate applications.
Producer
An application or component that creates and sends messages to the broker. Producers initiate the flow of data through your messaging ecosystem, pushing information to queues or topics for downstream processing.
Consumer
The receiving end of your message pipeline. Consumers subscribe to or pull messages from the broker, processing the data according to your application's business logic.
Queue
A point-to-point messaging destination where each message is delivered to exactly one consumer. Queues implement a first-in, first-out (FIFO) model by default, ensuring orderly message processing. When multiple consumers connect to a single queue, the broker distributes messages among them in a load-balanced fashion.
- Buffer message traffic spikes so downstream systems are not overloaded
- Buffer messages when a downstream system is offline for planned or unplanned outages
- Provide reliable transmission of messages across cloud regions, data centers, or physical locations by gracefully handling network interruptions
- Optimize data transmission to target systems using stateful connections with less overhead than REST API or other HTTP-based approaches
Topic
A publish-subscribe messaging destination enabling one-to-many communication. When a producer sends a message to a topic, all active subscribers receive a copy. This pattern excels for broadcasting events across multiple interested parties simultaneously.
JMS (Jakarta Message Service)
The Java API specification that defines a standard interface for messaging operations. ActiveMQ provides majority of Jakarta Messaging 3.1/JMS 2.0 support, full JMS 1.1 support including a complete client implementation with JNDI integration.
Jakarta EE Migration
The transition of Apache ActiveMQ from the legacy Java EE namespace (javax.jms.*) to the modern Jakarta EE namespace (jakarta.jms.*). This transition represents a significant milestone in ActiveMQ's evolution, bringing the mature codebase into alignment with the contemporary Jakarta ecosystem.
AMQP (Advanced Message Queuing Protocol)
An open standard application layer protocol for message-oriented middleware. Apache ActiveMQ is a mature, open-source, standards-based message broker that supports JMS, MQTT, STOMP, and AMQP. This multi-protocol support enables you to integrate multi-platform applications using this ubiquitous protocol for cross-language and cross-platform interoperability.
STOMP (Simple Text Oriented Messaging Protocol)
A lightweight, text-based protocol designed for simplicity and ease of implementation. As part of ActiveMQ's standards-based approach, STOMP support enables message exchange between web applications, including STOMP over websockets for browser-based clients.
OpenWire
The native binary protocol of ActiveMQ, optimized for performance and feature completeness. OpenWire delivers the full spectrum of ActiveMQ capabilities with maximum efficiency for Java-based clients using the Jakarta Messaging API (JMS).
MQTT (Message Queuing Telemetry Transport)
A lightweight publish-subscribe protocol originally designed for constrained devices and low-bandwidth networks. ActiveMQ's MQTT support, as part of its multi-protocol architecture, makes it an excellent choice for managing IoT devices and mobile applications.
Architecture Components
Destination
The logical endpoint where messages are sent and received. Destinations come in two primary forms: queues for point-to-point messaging and topics for publish-subscribe patterns.
Connection
The communication link between a client application and the ActiveMQ broker. Connections manage the underlying network resources and serve as the foundation for creating sessions.
Session
A single-threaded context for producing and consuming messages. Sessions provide transactional boundaries and acknowledgment modes, giving you fine-grained control over message processing semantics.
Message
The fundamental unit of data exchange in ActiveMQ. Messages contain a header with metadata, optional properties for additional attributes, and a body carrying the actual payload.
Durable Subscriber
A topic subscriber whose subscription persists even when the subscriber disconnects. The broker retains messages published during the subscriber's absence, delivering them upon reconnection. This ensures no messages are lost for critical consumers. A durable subscriber on a Topic is very similar to a queue.
Virtual Destination
An abstraction layer that decouples producers from the underlying destination topology. Virtual destinations enable sophisticated routing patterns, including composite destinations and wildcards, without modifying producer or consumer code.
Virtual Topic
A powerful ActiveMQ feature that combines the broadcast semantics of topics with the load-balancing and persistence benefits of queues. Producers publish to a topic using a naming convention (typically prefixed with VirtualTopic.), while consumers subscribe to automatically created queues that follow a pattern like Consumer.*.VirtualTopic.>. This approach allows multiple consumer groups to each receive all messages while distributing load among consumers within each group. Virtual topics solve the common challenge of scaling durable topic subscribers without message duplication or complex client-side logic.
Network of Brokers
A topology where multiple ActiveMQ brokers connect to form a distributed messaging fabric. This architecture enables horizontal scaling, geographic distribution, and fault tolerance across your infrastructure. Connected ActiveMQ brokers can dynamically respond to consumer demand by moving messages between nodes in the background.
Active-Standby Configuration
A high-availability deployment pattern (previously referred to as Master-Slave) where brokers are paired together so that if a master fails, the slave takes over. This configuration ensures clients can access their important data and eliminates costly downtime.
High Availability
ActiveMQ achieves high availability using various architectures. This approach ensures message persistence and broker failover capabilities meet application requirements, protecting your critical data from system failures.
Persistence and Storage
KahaDB
The default journaled message store for ActiveMQ, designed for high performance and reliability. KahaDB uses a file-based storage approach optimized for messaging workloads, providing fast message persistence and automatic recovery.
JDBC Persistence
A storage adapter enabling ActiveMQ to persist messages to relational databases. JDBC persistence integrates with your existing database infrastructure, providing an alternative to file-based storage when relational database integration is preferred.
Message Cursor
The internal mechanism ActiveMQ uses within queues and topics to track which messages are pending delivery to consumers. Cursors manage memory efficiently by paging messages between memory and disk based on consumption rates and resource constraints.
Queue Operations and Management
Queue Browse
An operation that inspects messages in a queue without consuming them. Queue browsing provides visibility into pending messages for debugging, monitoring, and operational verification. Standard JMS browsing operates within the configured maxBrowsePageSize limit (default: 400 messages).
- Verifying authentication and authorization configurations are functioning correctly
- Inspecting dead letter queue contents to diagnose processing failures
- Capturing a snapshot of messages for out-of-band viewing, sorting, or filtering
Queue Search
An advanced operation available in HYTE MQ that allows searching of messages across an entire queue, overcoming the maxBrowsePageSize (default: 400 messages) limitation inherent in Apache ActiveMQ queue browsing.
- Locating messages at the end of large queues exceeding the browse page size limit
- Finding messages anywhere in a queue matching specific text body filters
- Retrieving messages for sorting, filtering, or downloading for further processing
Queue Copy
An operation combining browse and send functionality to duplicate messages between destinations. Queue copy supports JMS Selector queries for filtering which messages are transferred.
- Copying messages between queues on the same ActiveMQ server
- Transferring messages between different ActiveMQ servers
- Cross-platform message migration, such as ActiveMQ to IBM MQ
Queue Purge
A native ActiveMQ operation that clears all messages from a queue without backup capability.
- Clearing queues in non-production environments before new test iterations
- Removing accumulated messages from dead letter queues in production after analysis
Queue Delete
A native ActiveMQ operation that removes a queue from the server entirely.
- Removing and recreating queues during non-production testing cycles
- Rapidly clearing all messages when speed is prioritized over queue preservation
Message Delete
A targeted removal operation using JMS Consume to remove specific messages from a queue. Messages can be removed by count, messageId, or JMS Selector query.
- Removing specific malformed messages from application queues
- Deleting problematic messages from dead letter queues before reprocessing remaining messages
Advanced Features
Advisory Messages
System-generated messages that report on broker events and statistics. Advisories provide visibility into connection lifecycle, destination creation, message expiration, and other operational metrics. Normal application code (outside of a few specialized use cases) does not typically produce or consume Advisory Messages.
Dead Letter Queue (DLQ)
A special destination where the broker routes messages that cannot be successfully delivered to application consumers. The Broker will move messages to a DLQ after exhausting retry attempts or encountering processing failures, enabling investigation and reprocessing. Dead Letter Queues also provide applications a straightforward solution to the problem of how to handle messages that are malformed or mistakenly placed in the wrong destination.
Message Groups
A feature that ensures all messages sharing a common group identifier are processed by the same consumer. Message groups maintain ordering and affinity for related messages while still distributing load across your consumer pool.
Prefetch Limit
A configuration parameter controlling how many messages the broker dispatches to a consumer ahead of acknowledgment. Tuning prefetch balances throughput against fair distribution when multiple consumers compete for messages.
maxBrowsePageSize
A configuration parameter that limits the number of messages returned during a queue browse operation. The default value is 400 messages. This setting impacts browse, copy, and certain search operations, making it an important consideration when working with large queues.
Redelivery Policy
The rules governing how ActiveMQ handles message redelivery after processing failures. Redelivery policies define retry counts, delay intervals, and backoff multipliers for sophisticated error-handling strategies.
Selector
A filter expression that consumers use to receive only messages matching specific criteria. Selectors evaluate message headers and properties using SQL-like syntax, enabling precise message routing at the consumer level.
- Filtering which messages are copied during queue-to-queue transfers
- Targeting specific messages for deletion based on header or property values
- Searching for messages matching criteria within large queues
Transaction
A unit of work encompassing multiple messaging operations that succeed or fail atomically. Transactions ensure consistency when your application logic requires all-or-nothing message processing semantics.
Acknowledgment Mode
The strategy defining when consumers confirm successful message receipt to the broker. Options range from automatic acknowledgment, transacted, and client-controlled confirmation, giving you control over delivery guarantees.
Message Load-Balancing
A capability where ActiveMQ distributes messages across multiple connected brokers or consumers to optimize resource utilization and throughput. This feature allows the system to dynamically respond to consumer demand.
Enterprise Integration Patterns
Established design patterns describing how multiple applications interact and integrate with each other. Asynchronous messaging sits at the heart of this integration, and ActiveMQ makes it straightforward to leverage these patterns via Apache Camel routes deployed directly on the broker.
Embedded Deployment
A deployment option where ActiveMQ runs within your application process rather than as a standalone broker. ActiveMQ can be configured with a small footprint, making embedded deployment viable for applications requiring simple, powerful messaging semantics with easy message exchange capabilities.
Pluggable Architecture
The extensible design philosophy of ActiveMQ that has served many generations of applications. This long-established architecture allows components to be added, removed, or replaced to meet specific messaging requirements.
Message Data Operations
Message Body Download
An operation that extracts message body content in its native format, preserving the original data structure whether JSON, XML, binary, or other formats.
- Working with message payloads directly in their native format
- Extracting data for external processing or analysis tools
Message Export (Body + Metadata)
A comprehensive export operation that captures message body, JMS Headers, and property data in a standard JSON or XML format. Message bodies are stored as base64 encoded byte arrays to support all text encodings including Unicode and international character sets.
- Offline message correction and data remediation workflows
- Modifying message body contents, headers, or properties before re-import
- Creating complete message backups for compliance or recovery purposes
Messaging Task Archive
A comprehensive export of messaging operation data including execution parameters, status information, and optionally all messages involved in the task. The archive format uses a zip structure containing XML configuration data and message files.
- Maintaining backups of messaging operations for audit or recovery
- Restoring messages from previous delete or move operations
- Transferring messaging task configurations between environments
Version Evolution and Roadmap
ActiveMQ 6.x Series
The current major version line of Apache ActiveMQ, representing the evolution from the 5.x series. The 6.x series incorporate the Jakarta EE transition and ongoing modernization development bringing new features and improvements.
ActiveMQ Classic
A temporary designation for the original Apache ActiveMQ broker used to distinguish it from other ActiveMQ subprojects. This name is no longer in use.