Delayed Redelivery

To give applications time to recover from a temporary inability to process a message, this feature allows for the delayed redelivery of messages to clients who are consuming guaranteed messages using local transactions. Delayed redelivery is controlled by a timer and is triggered by a client-initiated transaction rollback. While the redelivery timer is running, the consumer flow is blocked if it participated in a rolled back transaction, and message delivery to the application is suspended until the timer expires. After a client-initiated transaction rollback, message delivery will be suspended even if the event broker is in a state where no message redelivery will occur once the messages start flowing again; for example if message redelivery is disabled on the event broker, or the messages have expired on the event broker. A multiplier is used to allow for exponential back-off of redelivery attempts.

Delayed redelivery is supported only in thePubSub+ JCSMP API and PubSub+ JMS API. It is not supported in thePubSub+ Messaging APIs for C, .NET, Java RTO, JavaScript, Node.js, Python, or Go.

Delayed redelivery is a controlled availability (CA) feature. Please contact Solace to find out if this feature is supported for your use case.

The entire delayed redelivery configuration is performed on a PubSub+ event broker and transferred to the consumer flow upon a bind request to a queue or topic endpoint. Configuration on a PubSub+ event broker side can be updated only when no client is connected to the queue and connectivity to the queue is disabled. In other words, you cannot change, override, or review the configuration using the API.

For more information about configuring delayed redelivery on an event broker, see Configuring a Message Redelivery Delay (queues), or Configuring a Message Redelivery Delay (topic endpoints).