PubSub+ Message Handling Features: Reject-Message-to-Sender-on-Discard

Thus far in the message handling features blog series we have looked at message expiry and dead message queues. In this blog post we will cover the persistent messaging feature Reject Message to Sender on Discard. A long name, and an important endpoint property for defining certain scenarios when publishers should receive negative acknowledgements. For short, we will refer to the feature in this blog as Reject-to-Sender.

What is the Reject-to-Sender endpoint property?

Reject-to-Sender defines when a publisher should receive a negative acknowledgement if a message is rejected from an endpoint. This property is typically used when there are multiple consumers that require the exact same data. The configuration could look something like the below; each consumer has its own queue, and each queue has the same subscription.

Each of these consumers will receive the same messages because they are using persistent delivery and they all have the same subscription. However, if one consumer is slow or offline, its queue could fill up.

In this scenario, messages could still be stored in Q1 and Q2, but as Q3 is full, it would not have any room for new messages. Reject-to-Sender being enabled on these queues ensures that a message is stored on all 3 queues, or none of the queues. Almost like an ‘all or nothing’ property for endpoints that share subscriptions.

When the message is rejected from Q3, an error (or negative acknowledgement) is sent back to the publisher and the message is not stored on any of the three queues; it is then up to the publisher to resend the message.

Now, if Q3 had Reject-to-Sender disabled in this scenario, the message would be stored on Q1 and Q2, and the publisher would not receive any error message. This is regardless of whether Q1 and Q2 have the Reject-to-Sender property enabled or not.

How do I use Reject-to-Sender?

Reject-to-Sender is the property of a guaranteed endpoint and can be enabled/disabled as an endpoint setting. There are three options when configuring Reject-to-Sender:

• ‘When Queue Enabled’ refers to the queue admin status – if the queue is enabled, Reject-to-Sender is enabled
  • If the queue is administratively shutdown, this queue will not have an impact on sending negative acknowledgements to the publisher. Negative acknowledgements are only sent if a message is rejected & the queue is enabled. This is the most common setting for the Reject-to-Sender property.
• ‘Always’ treats Reject-to-Sender as enabled even when the queue is administratively shutdown
  • This is the least common setting for this property as messages would always be negative acknowledged to the publisher when a queue is shutdown.
• ‘Never’ treats Reject-to-Sender as disabled
  • This setting is used when a queue should not be included in the ‘all or nothing’ functionality. An example is when a queue bridges data from a Production environment to UAT/Test. If this queue were to fill up, you would not want it to affect Production processing of data.

By default, Reject-to-Sender is set as ‘When Queue Enabled’ for queues, and is disabled for topic-endpoints.

When messages are not able to be saved to a queue, the queue statistics will increment.

If you found this post useful, visit the queue properties section of our docs, and our PubSub+ for Developers page for more information. If you have any questions about queues and topic endpoints, try posting them to the Solace Developer Community.

Leah Robert

I have worked at Solace as a Customer Support Engineer, and as a Global Training Professional. I help customers to migrate from a siloed, monolithic architecture to an Event Driven Architecture. Solace PubSub+ enables the movement of data in an asynchronous manner, allowing distributed applications to seamlessly connect over any protocol.

See all posts written by Leah Robert