All Superinterfaces:
Lifecycle

public interface DurableQueues extends Lifecycle
The DurableQueues concept supports intra-service point-to-point messaging using durable Queues that guarantee At-Least-Once delivery of messages.
The only requirement is that message producers and message consumers can access the same underlying durable Queue storage.

In a service oriented architecture it's common for all deployed instances of a given service (e.g. a Sales service) to share the same underlying database(s). As long as the different deployed (Sales) services instances can share the same underlying database, then you use the DurableQueues concept for point to point messaging across all deployed (Sales service) instances in the cluster.
If you need cross-service point to point messaging support, e.g. across instances of different services (such as across Sales, Billing and Shipping services), then you need to use a dedicated distributed Queueing service such as RabbitMQ.

This library focuses on providing a Durable Queue supporting message redelivery and Dead Letter Message functionality and comes in two flavours PostgresqlDurableQueues and MongoDurableQueues which both implement the DurableQueues interface.

Durable Queue concept that supports queuing a message on to a named Queue. Each message is associated with a unique QueueEntryId
Each Queue is uniquely identified by its QueueName
Queued messages can, per Queue, asynchronously be consumed by a QueuedMessageHandler, by registering it as a DurableQueueConsumer using consumeFromQueue(QueueName, RedeliveryPolicy, int, QueuedMessageHandler)
The Durable Queue concept supports competing consumers guaranteeing that a message is only consumed by one message handler at a time

The DurableQueueConsumer supports retrying failed messages, according to the specified RedeliveryPolicy, and ultimately marking a repeatedly failing message as a Poison-Message/Dead-Letter-Message.
The RedeliveryPolicy supports fixed, linear and exponential backoff strategies. The DurableQueues supports delayed message delivery as well as Poison-Message/Dead-Letter-Messages, which are messages that have repeatedly failed processing.
Poison Messages/Dead-Letter-Messages won't be delivered to a DurableQueueConsumer, unless they're explicitly resurrected call resurrectDeadLetterMessage(QueueEntryId, Duration)

Ordered Messages
If you're queuing with OrderedMessage then, IF and only IF, only a single cluster node is consuming from the Queue, such as with an Inbox or Outbox configured with MessageConsumptionMode.SingleGlobalConsumer (which uses a FencedLock to coordinate message consumption across cluster nodes) in order to be able to guarantee that OrderedMessage's are delivered in OrderedMessage.getOrder() per OrderedMessage.getKey() across as many parallel message consumers as you wish to use.