Configuring Dead Message Queues

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

Message delivery to the client fails and the number of redelivery attempts for the message exceeds the Max Redelivery value for the original destination endpoint.
A message TTL value has been exceeded and the endpoint is configured to respect message TTL expiry times.
Message delivery was rejected by the consuming client.

The default behavior for messages that are removed from a queue or topic endpoint depends on the version deployed on your event broker:

In version 10.25.9 and earlier, messages removed from the endpoint are deleted. However, messages flagged as DMQ-eligible by the publishing client can instead be sent to a DMQ assigned to the endpoint.
In version 10.25.10 and later, all messages removed from the queue are sent to the DMQ assigned to the endpoint. However, you can instead configure the event broker to respect the DMQ-eligible flag set by the publisher, effectively preserving the behavior from earlier versions.

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 Event Broker CLI. For information about configuring DMQs in Broker Manager, see Configuring Dead Message Queues for Solace Cloud or Configuring Dead Message Queues for software event brokers and appliance event brokers.

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 initially set by the publishing client. However, this setting can be overridden by the endpoint's respect-dmq-eligible configuration. See Configuring DMQ Eligible Flag Behavior for more information.

For information on setting DMQ-eligibility at the publisher level:

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.

Configuring DMQ Eligible Flag Behavior

You can configure whether an endpoint respects the DMQ-eligible flag provided by the publisher. This setting determines whether messages that are not marked as DMQ-eligible by the publisher can still be moved to a DMQ.

For Queues and Topic Endpoints

To configure whether a queue respects the DMQ-eligible flag provided by the publisher, see Enforcing Whether to Respect DMQ-Eligible Flags

To configure whether a topic endpoint respects the DMQ-eligible flag provided by the publisher, see Enforcing Whether to Respect DMQ-Eligible Flags.

For Endpoint Templates

To configure whether a queue created from a given template respects the DMQ-eligible flag provided by the publisher, see Setting Respect DMQ-Eligible Flags

To configure whether a topic endpoint created from a given template respects the DMQ-eligible flag provided by the publisher, see Setting Respect DMQ-Eligible Flags.

For these settings to take effect, the Message VPN must have allow-dmq-eligible-endpoint-override enabled. See Enabling Endpoints to Override DMQ-Eligible Flags for more information.

Feature Interactions

Using High Availability

Solace 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 appliance event brokers) 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. Solace recommends that you don't disable ACK propagation.

Provide feedback