Integration / ActiveMQ Interview Questions Basics

Apache ActiveMQ is an open-source message broker written in Java that implements the JMS (Java Message Service) specification. It lets independent applications exchange data asynchronously by sending messages through queues or topics instead of calling each other directly.

Because the broker sits between producers and consumers, either side can go offline temporarily without losing messages, which decouples timing and scaling concerns. ActiveMQ supports multiple protocols (OpenWire, STOMP, MQTT, AMQP) and client languages, making it a common choice for enterprise integration, order-processing pipelines, and event-driven microservices where reliability and loose coupling matter more than raw throughput.

JMS is a Java API specification, not a product, that defines a standard way for Java applications to create, send, receive, and read messages. It describes interfaces such as ConnectionFactory, Destination, Session, and MessageProducer/Consumer that any compliant broker must support.

ActiveMQ, Artemis, and IBM MQ are all examples of brokers that implement this contract. Because the API is standardized, application code written against JMS interfaces can often switch brokers with minimal changes, which is why JMS is described as vendor-neutral messaging middleware for Java.

JMS defines two core messaging models that determine how a message travels from sender to receiver.

• Point-to-Point - messages are placed on a queue and delivered to exactly one consumer.
• Publish-Subscribe - messages are sent to a topic and delivered to every active subscriber.

Both models share the same JMS API, differing only in the destination type used.

In practice, the model is chosen by which destination interface the application uses: Queue/QueueSender/QueueReceiver for point-to-point, or Topic/TopicPublisher/TopicSubscriber for publish-subscribe. Since JMS 1.1, a unified domain lets the same Session and generic Destination interfaces work with either model, so code does not have to be written twice for queue-based and topic-based messaging.

A message broker is a middleware server that receives messages from producers, stores them temporarily, and routes them to the correct consumers. It handles concerns like message persistence, delivery guarantees, retry logic, and protocol translation so applications on either end don't have to implement this plumbing themselves.

ActiveMQ, RabbitMQ, and Kafka are all message brokers, though they differ in delivery model and performance characteristics. In practice, a broker lets a slow or temporarily unavailable consumer catch up later without the producer being blocked or losing data.

A Queue is a destination used for point-to-point messaging: each message placed on the queue is delivered to and consumed by exactly one receiver, even if several consumers are listening. Once a consumer acknowledges the message, it is removed from the queue.

Queues are typically used for work-distribution scenarios such as order processing or task queues, where you want load balanced across multiple worker instances but each unit of work handled only once.

Multiple consumers can still listen on the same queue for scalability - ActiveMQ simply hands each incoming message to only one of them, load balancing work across the pool rather than duplicating it.

A Topic is ActiveMQ's publish-subscribe destination: a message sent to a topic is delivered to every consumer currently subscribed to it. If no subscribers are listening at the time, non-durable subscribers simply miss the message.

Topics fit fan-out scenarios such as broadcasting price updates or notifications to multiple interested services, as opposed to a queue where only one consumer handles a given message.

A single topic can have many independent subscribers, each unaware of the others, which makes topics a natural fit whenever more than one system needs to react to the same event without one blocking or interfering with another.

The core building blocks of an ActiveMQ deployment are:

• Broker - the server process that accepts connections and routes messages.
• Producer - client that sends messages to a destination.
• Consumer - client that receives messages from a destination.
• Destination - a Queue or Topic that messages are addressed to.
• Transport Connector - the protocol endpoint (OpenWire, STOMP, MQTT, AMQP) clients connect through.
• Persistence Adapter - KahaDB, JDBC, or LevelDB, used to store messages durably.

These pieces are wired together in activemq.xml, the broker's main configuration file.

A ConnectionFactory is the JMS object a client uses to create a Connection to the broker. It encapsulates the broker URL, and often credentials and failover settings, so application code doesn't hard-code connection details.

Instead of establishing a socket manually, a client looks up or instantiates a ConnectionFactory, calls createConnection(), then createSession() to start producing or consuming messages. Pooled connection factories are common in production to avoid the overhead of opening a new connection per request.

Administered connection factories can also be looked up via JNDI, letting the broker address be changed centrally without touching application code.

A Producer (MessageProducer in JMS terms) is the client component responsible for creating and sending messages to a specific destination, either a Queue or a Topic. It is created from a Session and can set delivery mode, priority, and time-to-live per message.

A producer doesn't need to know who, if anyone, is consuming the message - it simply hands the message to the broker, which takes responsibility for delivery.

Producers can also be created without specifying a destination up front, letting the same producer send to different destinations chosen at send time, which is convenient when a single service publishes to several queues.

A Consumer (MessageConsumer) is the client that receives messages from a Queue or Topic. It can pull messages synchronously via receive(), or process them asynchronously through a registered MessageListener callback.

Consumers are also responsible for acknowledging messages according to the session's acknowledgment mode, which tells the broker when it is safe to remove or redeliver a message.

A Consumer can also be created with a message selector, a SQL-like filter expression evaluated against message headers and properties, so it only receives messages matching specific criteria rather than every message sent to the destination.

A Durable Subscriber is a Topic consumer that registers with a unique client ID and subscription name so the broker retains messages for it even while it is disconnected.

Regular topic subscribers only receive messages published while they are actively connected; a durable subscriber, by contrast, catches up on everything sent during its downtime once it reconnects. This is useful when a subscriber must never miss an event, such as an audit or billing service listening to a notifications topic.

Only one active connection may use a given durable subscription at a time, so restarting a durable subscriber client with the same identifiers simply resumes the same backlog rather than creating a second parallel subscription.

ActiveMQ supports several wire protocols depending on client type and use case:

A single broker instance can expose several of these transports simultaneously, each on its own port, so a Java service can connect over OpenWire while an IoT device connects to the same broker over MQTT. Choosing a protocol is mostly about the client ecosystem: use OpenWire for Java-to-Java traffic where performance matters most, and reach for STOMP, MQTT, or AMQP when clients are written in other languages or run on constrained hardware.

OpenWire is ActiveMQ's native, binary wire protocol optimized for Java clients. It's the default transport when connecting via the standard tcp:// URL and generally offers lower overhead than text-based protocols like STOMP because it encodes JMS objects directly rather than serializing to text.

Because it's ActiveMQ-specific, OpenWire clients aren't portable to other brokers, so cross-broker integrations typically fall back to AMQP or STOMP instead.

OpenWire also supports advanced JMS features like message compression and prioritized delivery natively, which is one reason performance-sensitive Java applications default to it rather than switching to a cross-language protocol.

The ActiveMQ web console is a browser-based admin UI, typically at http://localhost:8161/admin, that lets an operator inspect queues and topics, view pending message counts, browse message contents, purge destinations, and monitor connected consumers/producers in real time.

It's handy for quick diagnostics - like confirming messages are stuck on a queue or a consumer isn't acknowledging - without writing any JMX or CLI tooling.

It also shows connected network-of-brokers links and JVM-level statistics, which is often the fastest way to spot a broker that's silently disconnected from its peers before it shows up as a bigger production issue.

Download the binary distribution, extract it, and start the broker from its bin directory:

tar -xzf apache-activemq-5.18.0-bin.tar.gz
cd apache-activemq-5.18.0
bin/activemq start

Use bin/activemq console instead to run it in the foreground for debugging. Then confirm it's up by hitting the web console at :8161/admin with the default credentials admin/admin. A compatible JDK (Java 8+) must be installed with JAVA_HOME set beforehand.

On Windows, the equivalent is running activemq.bat from the same bin directory. In containerized environments, the official ActiveMQ Docker image offers a quicker path that skips manual JDK setup on the host machine entirely.

JMS sessions in ActiveMQ support four acknowledgment modes:

• AUTO_ACKNOWLEDGE - acknowledged automatically right after the message is received.
• CLIENT_ACKNOWLEDGE - the client explicitly calls acknowledge().
• DUPS_OK_ACKNOWLEDGE - lazy acknowledgment that tolerates occasional duplicates for better throughput.
• SESSION_TRANSACTED - acknowledgment is tied to a transaction commit.

Choosing between them is a throughput-versus-safety trade-off: AUTO_ACKNOWLEDGE and DUPS_OK_ACKNOWLEDGE are simplest and fastest but riskier if processing fails after the message is already considered handled, while CLIENT_ACKNOWLEDGE and SESSION_TRANSACTED give the application explicit control over exactly when a message is considered done, at the cost of a little extra code.

A Dead Letter Queue (DLQ) is a special destination, ActiveMQ.DLQ by default, where messages land after they exceed their configured redelivery attempts or expire without being successfully processed.

Instead of silently dropping a poisoned message, the broker moves it aside so an operator or a dedicated process can inspect, fix, and replay it later.

Messages that land in the DLQ keep their original headers and properties intact, so an operator inspecting them in the web console can usually tell which destination and application they came from, even without checking application logs.

Virtual Destinations let ActiveMQ blend queue and topic semantics. A Virtual Topic lets multiple durable, queue-backed consumer groups each get their own copy of every message, combining topic fan-out with queue-style load balancing per group.

A Composite Destination lets one send target fan out to several underlying queues or topics in a single call. They're commonly used so several independent consumer groups can each reliably process every event without needing true durable topic subscriptions.

Both features are configured declaratively in destination policies inside activemq.xml rather than requiring any client-side code changes, which means existing producers and consumers do not need to know virtual routing is happening underneath them.