Integration / ActiveMQ Interview Questions Advanced

KahaDB is ActiveMQ's default file-based persistence adapter. It combines a write-ahead log with an index so persistent messages survive broker restarts without requiring random-access disk writes for every operation.

When a persistent message arrives, KahaDB appends it to the current active data log file sequentially, which is cheap because it requires no disk seek, then updates its page-file index entry pointing to that offset. Message removal after acknowledgment doesn't rewrite the log entry in place; instead it marks the entry as deleted in the index. A background process periodically checks whether every message in an older data log file has been marked deleted, and once a whole file is fully consumed, KahaDB deletes that entire file rather than compacting individual records, keeping the reclaim cost low.

On broker restart, KahaDB replays the data logs to rebuild its index, which is why very large uncompacted logs can slow down startup after an unclean shutdown. This log-structured design trades some read-path indirection for very fast sequential writes, which is why KahaDB generally outperforms JDBC persistence for a single, locally-attached broker, though it doesn't natively support shared storage across multiple broker instances the way a database can.

Because reclaiming a file requires every message in it to be fully consumed first, a single long-lived unacknowledged message can indefinitely pin down an entire data log file, which is a common, if underappreciated, cause of disk usage that keeps climbing even though most traffic is flowing normally.

A message travels through several distinct stages between the moment a producer creates it and the moment a consumer finishes with it.

First, the producer creates the message via the Session and calls send(), setting delivery mode, priority, and time-to-live. The broker receives it over a transport connector; if the delivery mode is persistent, it writes the message to KahaDB before the send is considered durable. The broker then enqueues the message on the destination's internal structure and dispatches it to a waiting consumer, respecting that consumer's prefetch limit and the message's priority. The consumer receives it either synchronously via receive() or asynchronously via a MessageListener, processes it, then acknowledges it according to the session's ack mode. On acknowledgment, the broker removes the message from its store; if no acknowledgment ever arrives, the redelivery policy kicks in and, after enough attempts, routes the message to the Dead Letter Queue instead.

Two details matter for correctness along this path. First, if the producer uses persistent delivery with the default synchronous send, the broker doesn't confirm the send back to the producer until the write to KahaDB has actually completed, so a producer that gets a successful response can trust the message won't vanish on a crash moments later. Second, the consumer's prefetch buffer means several messages may already be sitting client-side, dispatched but unacknowledged, before any single one is processed - which is why a consumer crash can leave multiple in-flight messages needing redelivery, not just the one currently being handled when it died.

In a JMS transacted session (createSession(true, ...) or SESSION_TRANSACTED), all sends and receives performed between commit() calls are grouped into one atomic unit of work. Messages sent within the transaction aren't visible to consumers until commit() succeeds; calling rollback() instead means none of the sent messages are ever delivered. Messages received within the transaction aren't permanently removed until commit either; rollback returns them to the destination, often redelivered with an incremented redelivery counter, as if they had never been taken.

Internally, the broker tracks a transaction context tied to the session, buffering the enqueue and dequeue operations, and only applies them durably to the destination and persistence store atomically once commit() is received - so either every operation in the transaction takes effect or none do. This is what makes the classic "receive from Queue A, process, send to Queue B" pattern safe: a failure partway through processing can roll back both the removal from A and the send to B together, avoiding a state where the message vanishes from A but never makes it to B.

One consequence worth knowing: a transacted session's commit() and rollback() apply to every send and receive performed on that session since the previous boundary, not just the last operation, so mixing unrelated units of work on a single transacted session can accidentally roll back or commit more than intended. This is why applications typically dedicate a session, and its transaction boundary, to one coherent unit of work, such as a single "receive, transform, forward" cycle, rather than sharing one long-lived transacted session across unrelated processing paths.

Traditional Master-Slave HA in ActiveMQ Classic relies on an exclusive lock on a shared persistence store, either a shared-filesystem KahaDB lock file or a shared JDBC database, to guarantee only one broker instance actively serves clients at a time.

Multiple broker processes start up pointing at the same store; the first one to acquire the exclusive lock becomes master and starts accepting connections, while the others block waiting for the lock, acting as passive slaves that hold no client connections. If the master crashes or shuts down, its lock is released, and one of the waiting slaves acquires it and takes over as the new master. Because they share the same underlying store, the new master resumes with exactly the messages and state the failed master last persisted, without needing to synchronously replicate anything itself - the storage layer handles consistency. Clients configure a failover: transport URL listing all broker addresses so they automatically reconnect to whichever instance is currently master after a failover event.

A practical detail worth knowing: because failover relies on releasing and re-acquiring a lock on shared storage, the failover window isn't instantaneous - there's a brief gap between the master disappearing and a slave detecting the released lock, during which in-flight requests may need to be retried by the client once reconnected. This lock-based design also means the shared store itself, whether a filesystem or database, becomes the single point of failure the whole HA scheme depends on, which is why that store is usually put on its own redundant storage, like a SAN or replicated filesystem, rather than a single disk.

A network of brokers connects multiple independent ActiveMQ instances via network connectors, letting messages hop from a broker close to the producer to a broker close to the consumer, without either client knowing about the other broker.

Each broker advertises its local consumers to its network-connected peers; when a producer sends a message to a broker that has no local consumer for that destination but knows a peer broker does, it forwards the message across the network connector to that peer, which then delivers it locally. This forms a store-and-forward mesh rather than a single shared queue: each broker retains its own persistence store, and messages travel only when there's demonstrated demand on the other side, avoiding needless duplication across brokers with no interested consumers.

Networks can be configured as one-way or duplex, and support multiple hops, though each hop adds latency and weakens ordering guarantees, since messages may now traverse different paths depending on where consumers happen to be connected. This pattern is common for geographically distributed deployments, such as a broker per data center, where producers and consumers talk to their local broker for low latency while still reaching consumers anywhere else in the network.

A subtlety worth calling out: network connectors forward based on demand signals, not blind broadcasting, but that demand information itself takes a moment to propagate between brokers when a new consumer first connects, so there can be a brief window right after a consumer subscribes where messages sent before the demand was known don't get forwarded retroactively. This is one reason network-of-brokers topologies are typically designed with stable, long-running consumer groups in mind rather than consumers that connect and disconnect frequently.

KahaDB writes persistent messages as sequential appends to local log files and maintains its own lightweight index, so a single store or remove operation is essentially one disk-sequential write plus an in-process index update. JDBC persistence routes every store and remove operation through a relational database driver instead, meaning network round-trips if the database isn't local, SQL parsing, transaction log overhead on the database's own side, and index maintenance on the database's tables - all latency that KahaDB's log-structured design avoids.

JDBC does buy something KahaDB alone doesn't: the ability to point multiple broker instances at the same shared database for certain HA topologies, plus reuse of existing database backup and replication tooling a team already operates. So the trade-off is throughput and latency, where KahaDB wins, versus operational reuse of existing database infrastructure, which is JDBC's niche. For a single high-throughput broker where persistence latency matters most, KahaDB is the default and generally correct choice; JDBC gets chosen for organizational or HA reasons more than raw speed.

There's also an operational dimension to the choice: KahaDB's data lives as opaque log files on local disk, which existing database-centric tooling, like backup jobs, replication, and monitoring dashboards built around SQL, simply can't inspect or manage, whereas JDBC persistence lets a broker's message store be backed up, restored, and monitored using exactly the same tooling a DBA team already runs for the rest of the organization's databases. Teams migrating from a legacy JMS provider that used JDBC persistence sometimes stick with JDBC initially purely to avoid retraining operations staff, even though a later move to KahaDB would likely improve throughput once the team is comfortable managing a new storage format.

ActiveMQ Classic doesn't scale like Kafka's partitioned log - a single Queue lives on a single broker - so horizontal scale is achieved through composition rather than built-in partitioning:

1. Network of brokers - spread different destinations or consumer groups across multiple connected broker instances so no single broker handles all traffic.
2. Client-side sharding - deliberately split traffic across several independent queues/brokers by a partition key, such as customer ID, where producers and consumers know which broker owns which shard.
3. Virtual Topics / composite destinations - fan messages out to multiple consumer groups that can then each scale their own worker pool independently.
4. Migrate hot destinations to dedicated broker instances so one noisy destination doesn't starve others sharing the same broker's resources.

None of these give Kafka-style automatic partition rebalancing - the sharding and routing logic has to be designed into the application or topology up front. If genuinely elastic, automatically rebalanced horizontal scaling is the primary requirement, that's usually a signal to evaluate Kafka or ActiveMQ Artemis clustering rather than to force it onto ActiveMQ Classic.

A practical illustration: an order-processing system might shard by region, running a separate broker, or queue, per region so that a spike in one region's traffic doesn't starve consumers processing another region's orders. Consumers for each shard only ever connect to their own broker or queue, and a new region can be added by standing up a new shard rather than reconfiguring the whole fleet. This kind of design has to be planned deliberately, though - unlike Kafka, ActiveMQ won't automatically redistribute partitions if one shard becomes hotter than the others; an operator has to notice the imbalance and manually rebalance which keys route to which shard.

Every destination in ActiveMQ has a configured memory limit representing how much of the broker's memory budget that destination's unconsumed messages may occupy. As messages accumulate on a destination, typically because consumers aren't keeping pace, the broker tracks the destination's current memory usage against that limit.

When usage crosses the limit and producer flow control is enabled (the default), the broker doesn't reject the next send outright. Instead it withholds the acknowledgment for the producer's send() call, which causes the client-side send, in synchronous mode, to block inside the API call until the broker signals that memory has freed up again, typically because a consumer processed and acknowledged enough messages to drop usage below the threshold. This pushes back-pressure all the way to the producer thread itself, throttling how fast new messages can enter the system, rather than letting the broker's memory grow unbounded and eventually crash with an OutOfMemoryError.

If a producer can't tolerate blocking, it can enable useAsyncSend or configure a sendTimeout, after which a blocked send throws a ResourceAllocationException instead of blocking indefinitely, giving the application a chance to handle the back-pressure explicitly rather than stalling.

It's worth distinguishing this destination-level memory limit from the broker's overall system usage limit, configured separately - a single busy destination can trigger its own flow control well before the broker as a whole is anywhere near its total memory ceiling, and conversely a broker approaching its global memory limit can apply flow control across many destinations simultaneously even if no single one has individually crossed its own limit. Getting these two limits sized appropriately relative to each other, and relative to the JVM heap, is a common source of tuning work on busy production brokers.

ActiveMQ doesn't provide automatic exactly-once semantics out of the box; by default, a redelivery after a failed acknowledgment can result in a consumer seeing the same message twice. To help applications detect that, ActiveMQ sets the JMSRedelivered flag to true on any message being redelivered, so a consumer can at least know a given message might be a duplicate of one it already partially processed.

For stronger protection, ActiveMQ ships an optional message-audit deduplication mechanism used internally, and configurable in network connectors to avoid re-forwarding the same message across a broker mesh. Applications commonly implement their own idempotency layer as well, having producers stamp a unique business ID on each message and consumers check that ID against a de-duplication store, such as a database unique constraint or a cache, before acting on it a second time.

Achieving genuine end-to-end exactly-once delivery ultimately requires this kind of application-level idempotency, because no message broker, including ActiveMQ, can guarantee exactly-once across an unreliable network without cooperation from the consumer's own processing logic.

It's also worth noting where duplicates most often originate in practice: a consumer that successfully processes a message but crashes, or loses network connectivity, before its acknowledgment reaches the broker will see that same message redelivered once it reconnects, even though the business-level work was already done. This is fundamentally a coordination problem between two independent systems, the broker and the consumer's own processing logic, and no amount of broker-side cleverness alone can close that gap - which is exactly why idempotency has to live in the consumer, checking a durable record of "have I already handled this ID" before acting, rather than being something the message broker can guarantee on the consumer's behalf.

On startup, ActiveMQ's persistence adapter, KahaDB by default, replays its data log files to reconstruct the in-memory index of which messages exist on which destinations and which transactions were in-flight but not yet committed at shutdown.

Any message that was durably stored and never acknowledged before the broker went down is restored to its destination exactly as it was, so consumers reconnecting after the restart see the same pending backlog they would have seen had the broker never gone down - messages are not lost or silently dropped. Transactions left uncommitted at the moment of shutdown are typically rolled back during this recovery, since a transaction is only durable once commit() has been fully applied.

If the shutdown was unclean, a crash rather than a graceful stop, KahaDB may need extra time to verify or repair its index against the log files before the broker can accept connections again, which is one reason very large, uncompacted data log directories can noticeably slow down startup after a crash. Non-persistent messages that existed only in memory at the time of the crash are gone permanently, since by design they were never written to disk.

It's also worth knowing that a broker's startup time after a crash is roughly proportional to how much unreclaimed log data KahaDB has to scan and validate, which is one practical reason operators keep an eye on KahaDB's total data directory size in production - a broker whose disk usage has silently grown unchecked, perhaps because a stuck durable subscriber is pinning old log files, can take noticeably longer to come back online after an unexpected outage than one whose store is regularly compacted.

Encrypt the wire with an ssl:// transport connector backed by a broker keystore and truststore, optionally setting needClientAuth for mutual TLS so clients must also present a certificate:

<transportConnectors>
  <transportConnector name="ssl" uri="ssl://0.0.0.0:61617?needClientAuth=true"/>
</transportConnectors>

<plugins>
  <simpleAuthenticationPlugin>
    <users>
      <authenticationUser username="app" password="changeit" groups="consumers,producers"/>
    </users>
  </simpleAuthenticationPlugin>
  <authorizationPlugin>
    <map>
      <authorizationMap>
        <authorizationEntries>
          <authorizationEntry queue=">" write="producers" read="consumers" admin="producers,consumers"/>
        </authorizationEntries>
      </authorizationMap>
    </map>
  </authorizationPlugin>
</plugins>

Layer in authentication next: simpleAuthenticationPlugin for a small static user list, or a JAAS/LDAP plugin for a real directory, so connections must supply valid credentials. Then add authorization so authenticated users are restricted to only the queues and topics their group is allowed to read, write, or administer. In production, credentials are usually externalized to a JAAS realm backed by LDAP or a database rather than hardcoded in activemq.xml, and keystores are rotated on a schedule.

Beyond the basics shown above, it's common to layer in a JAAS login module backed by LDAP or Active Directory instead of the static simpleAuthenticationPlugin user list, so that user accounts and group membership stay centrally managed rather than duplicated inside activemq.xml. It's also worth restricting the admin permission tightly, since a user with admin rights on a destination can purge it or change its configuration, which is a much bigger blast radius than simply being able to read or write messages. For defense in depth, many production deployments also disable the plain, unencrypted tcp:// connector entirely once the ssl:// connector is confirmed working, so a misconfigured client can't silently fall back to sending credentials or message payloads unencrypted over the network.

When rollback() is called on a transacted session, the broker undoes every operation buffered under that transaction's context since the last commit. Messages sent within the transaction are simply discarded and never delivered to any consumer, as if send() had never been called at all. Messages received within the transaction are returned to their original destination so they become available for redelivery, with ActiveMQ incrementing the message's redelivery counter and, if a redelivery policy is configured, applying a delay before the same or another consumer picks it up again.

Internally, the broker's transaction manager for that session tracks a list of pending enqueue and dequeue operations tagged to the transaction ID. commit() flushes them atomically to the persistence store and destination structures, while rollback() simply discards the enqueue operations and reverses the dequeue operations, restoring pre-transaction state without touching the persistence store at all. This design means a transaction failure never leaves the broker in a half-applied state - either the whole batch of sends and receives lands, or none of it does - which is exactly what lets applications safely retry a failed unit of work without worrying about partial side effects on the broker side.

One easy-to-miss detail is that rollback does not reset the redelivery delay clock for received messages the way a fresh send would - a message that has already been rolled back several times keeps accumulating its redelivery count, so if a redelivery policy with a maximum retry limit is configured, repeatedly rolling back the same problematic message will still eventually route it to the Dead Letter Queue rather than looping forever.