Exponential Backoff Retry

Owned by Allan Bernard
Last updated: Oct 13, 2023
3 min read

Calculating EBR

A room contains the following properties that are used to calculate if a message is valid:

  • message expiration: Duration in ms after which message expires. If set to 'null' or 0, messages never expire.

  • delivery delay: Duration in ms for delay between message delivery attempt to subscription.

  • delivery delay multiplier: An exponent by which delivery delay is increased exponentially between delivery attempts.

  • delivery attempts: Maximum number of delivery attempts for message. If set to 0, redelivery is not attempt.

Each subscription of type PUSH that belongs to a room can override any of the delivery delay, delivery delay multiplier and delivery attempts.

T() = deliveryDelay * deliveryDelayMultiplier ^ deliveryAttempt 

The ‘delivery’ parameters can be overridden by the subscriber on a per-subscription model (different subscribers can specify different retry policies), however the message expiration can not and is set by the rooms owner for all messages in that room, irrespective of subscription details.

 

Messaging API - Automated PUSH

The messaging-api is using reactive approach to implements automated push of messages to subscribers.

A subscription that is of type 'push' is retrieved from database and event is published to quarkus event-queue that triggers automated push of message for subscriptions. Quarkus built in reactive architecture goes into action and processes the events by event handlers or by working threads.

The events are then processed by a handler a the message is consumed from Artemis and delivered to subscription's push url.

The subscriber sends back ACK, and messaging-api acknowledge the message in Artemis.

The delivery attempt count and next calculated delivery delay will be stored (and submitted) in the message header. If the delivery is successful on the first try, those will be zero. In a situation if the delivery fails, the message delivery attempt is incremented and the EBR procedure is started.

The previous delivery attempts are checked from the header, then the next delivery delay is calculated based on either room configuration or subscription (if the subscriber has overridden that), and the message is publish back to Artemis with a deliveryDelay parameter.

The initial message received is acknowledge in order not to produce duplicate messages in Artemis.

Each message (event) send (, publish or republish) to Artemis (for each subscription) is logged under published_messages.

A correlation id is used to track messages (events) between Artemis and messaging-api (publishers and subscribers).

Artemis 

The message expiry is handled by Artemis out of the box. If a message is not delivered before the rooms expiry delay, the message is discarded.

The delivery delay that is counted in milliseconds and handled by Artemis. Artemis, when receiving a message with a set deliveryDelay will not deliver this message to the queue until the delivery delay has passed. This is an internal process and the subscriber will not be able to view or interact with messages that are not yet delivered to their queue.

In Artemis, each PULL subscription has it's own queue which has unique name (pattern: 'subscription-{subscription_id}').

For PUSH subscriptions a single reactive queue is used.

In Artemis, each room has it's own room which has unique name (pattern: 'room-{room_id}).

In Artemis, queues belong to addresses similar as subscriptions belonging to rooms.

A destination is combination of address and queue (pattern 'room-{room_id}::subscription-{subscription_id}').

A publisher can send one message to 1 or more destinations in a room. 

The destinations are resolved based on the room's subscriptions, event types, and event type versions.