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.
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.
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:
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.
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.[position] => [url] => https://solace.com/blog/author/leahrobert/ ) )