Configuring Dead Message Queues

You can create a dead message queue (DMQ) to receive messages that are discarded from one or more queues or topic endpoints when they can't be delivered to the subscribing client. By default, messages are discarded from an endpoint in the following circumstances:

the maximum time-to-live (TTL) value for the message has been reached and the endpoint is configured to respect message TTL expiry times.
the number of redelivery attempts to the consumer for a message has reached the max redelivery count value for the original endpoint.

Discarded messages are deleted unless a DMQ is configured to receive messages discarded by the queue or topic endpoint and the message is flagged as DMQ-eligible by the publisher.

Solace recommends that you use a separate DMQ for each queue and topic endpoint that needs one. Separate DMQs make it easier to manage dead messages from multiple queues and makes investigating DMQ messages easier.

For more information about DMQs, see Dead Message Queues.

Configuring a DMQ

This section provides information to configure DMQs using Solace CLI. For information about configuring DMQs in PubSub+ Broker Manager, see Configuring Dead Message Queues for PubSub+ Cloud or Configuring Dead Message Queues for software event brokers and appliances.

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 more information:

on Solace messaging APIs, see Dead Message Queue Eligibility.
on Solace REST messaging, see Solace-Specific HTTP Headers on setting Solace-DMQ-Eligible.
on JMS APIs, see Dead Message Queue Eligibility
for AMQP 1.0, every message is DMQ-eligible

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

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. Solacerecommends that you don't disable ACK propagation.

Provide feedback