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, 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.