Integration / ActiveMQ Interview Questions Advanced
1. Explain the internal working of ActiveMQ's KahaDB persistence store?
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 ...
2. Explain the lifecycle of a message from producer to consumer in ActiveMQ?
A message travels through several distinct stages between the moment a producer creates it and the moment a consumer finishes with it. sequenceDiagram participant P as Producer participant B as Broker participant S as KahaDB Store participant C as Consumer P->>B: send(message, deliveryMode) alt P...
3. Explain the execution flow of a transacted session in ActiveMQ?
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 mea...
4. How does ActiveMQ implement high availability using Master-Slave?
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...
5. How does a network of brokers work in ActiveMQ?
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...
6. Why is KahaDB preferred over JDBC persistence for high throughput?
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 re...
7. How do you scale ActiveMQ horizontally?
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: Network of brokers - spread different destinations or consumer groups across multiple connected broker ins...
8. Explain the internal working of producer flow control in ActiveMQ?
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 ...
9. How does ActiveMQ handle duplicate message detection?
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...
10. What happens internally when a broker restarts with pending persistent messages?
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 acknowl...
11. How do you secure ActiveMQ using SSL/TLS and authentication plugins?
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:
12. Explain the execution flow of a JMS transaction rollback in ActiveMQ?
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 ...
