Configuring Dead Message Queues

By default, Guaranteed messages are removed from a durable endpoint's message spool and discarded when:

  • the number of redelivery attempts for a message exceeds the Max Redelivery value for the original destination endpoint;
  • or, a message's Time-To-Live (TTL) value has been exceeded, and the endpoint is configured to respect message TTL expiry times.

If you don't want the messages to be discarded, they can be moved to a dead message queue (DMQ) assigned to the endpoint.

How DMQs Work

Any durable queue (including a partitioned queue) on the same Message VPN as the endpoint that the messages are being removed from can be assigned as a DMQ. If a partitioned queue is configured as a DMQ, any expiring message is put into the partitioned DMQ based on the hash of the message's partition key, or into partition 0 if there is no hash.

Messages that are flagged as DMQ-eligible by the publishing client will be sent to the endpoint's DMQ rather than be discarded.

However, if an endpoint's assigned DMQ doesn't exist, then the removed Guaranteed messages will still be discarded even if they are DMQ-eligible. By default, each durable endpoint is assigned a DMQ named #DEAD_MSG_QUEUE, but this queue doesn't pre-exist and must be created by a management user.

Setting the DMQ

To assign a specific DMQ for a durable queue, enter the following CONFIG command:

solace(configure/message-spool/queue)# dead-message-queue <name>

To assign a specific DMQ for a durable topic endpoint, enter the following CONFIG command:

solace(configure/message-spool/topic-endpoint)# dead-message-queue <name>

Where:

<name> is the name of an existing queue on the same Message VPN as the given endpoint.

The no version of this command, no dead-message-queue, resets the endpoint's assigned DMQ to the default of #DEAD_MSG_QUEUE.

Moving messages to the DMQ while new messages are also being spooled could consume a large amount of event broker spool resources. Solace recommends that there always be an online consumer connected to a DMQ for expired messages to reduce overall event broker spool usage requirements.

Setting the DMQ through Endpoint Templates

You can assign a specific DMQ for client created endpoints using an endpoint template. When client created endpoints are created dynamically using an API, the endpoint name will be matched to the endpoint template. Take a look at Endpoint Templates for more information.

To assign a specific DMQ for a client created queue using a queue template, enter the following CONFIG command:

solace(configure/message-spool/queue-template)# dead-message-queue <name>

To assign a specific DMQ for a client created topic endpoint using a topic endpoint template, enter the following CONFIG command:

solace(configure/message-spool/topic-endpoint-template)# dead-message-queue <name>

Where:

<name> is the name of an existing queue on the same Message VPN as the given endpoint.

The no version of this command, no dead-message-queue, resets the endpoint's assigned DMQ to the default of #DEAD_MSG_QUEUE.

Setting DMQ Eligibility and TTL

Setting DMQ-eligibility

A message's DMQ-eligibility is set by the publishing client. For instructions on setting, refer to the following:

Setting TTL

A message's TTL value may also be set by a publishing client, and / or it may also have a max-ttl value, which an endpoint can set when it receives the message.

Feature Interactions

Using High Availability

Solace PubSub+ event brokers in a high-availability (HA) group should have their clocks synchronized with a Network Time Protocol (NTP) server (PTP can also be used by appliances) for Guaranteed message expiry to work as expected in redundant configurations. If the backup event broker does not have the same clock time as the primary, then the message will not expire at the expected time if there is a failover between when the message is published and when it is set to expire. NTP server parameters can be configured from the CLI through the ntp-server CONFIG command.

Using Replication

If you're using replication, and ACK propagation is enabled for the endpoint (enabled is the default value), replicated messages on the standby site that exceed their TTLs will be discarded rather than moved to a DMQ. If you disable ack propagation, then the TTL timers will run independently at both sites and lead to differences between the messages spooled at each site. Note that Solace recommends that you don't disable ACK propagation.