Respool to queue

Abu

I was reading the behavior for Solace redelivery to consumer while assuming I have an exclusive queue with one consumer.

First :

Can you please let me know if the behavior is correctly understood ?

Solace redelivers messages on the transport level. Meaning the messages are redelivered only when a flow or connection is re-established while the ack was still underway/in-flight for that message before the unbind happened.

Second:

Is there an out-of-box capabality (without terminating the connection) where the messages are NACK-ed and sentback or respool-ed to the queue (for example when there were errors in processing that message by the subscribing application). The consumer should not remember the state for the message and rather treat it as a fresh message. This will certianly not help unless the consuming application is fixed to handle such mischievous messages. But this is in absence of using the Solace replay feature as we have brokers that are shared by different systems and the replay capabailty is not granular to the topic level.

Thanks in advance.

TomF

Hi @abu,

First is correct. Messages are delivered by the Solace API and presented to the Application. Providing the application is still connected and bound to the queue, the API has done its job, and is waiting for you to tell it you've finished with the message (by calling acknowledge). However, if the flow unbinds, the API/broker combination assumes something has gone wrong in the application. Messages that were sent to the API but not acked by the application are marked as redelivered. Next time an application binds they are resent and presented to the application again, provided the messages redelivery count isn't exceeded. The redelivery count functionality is there to prevent a badly formed message or application continuously failing and re-binding - the "poison message" scenario.

Second (nack): It's on the roadmap. Currently, your options are to unbind and rebind (resource intensive and a little painful) or initiate replay (which you've said you can't do.)

Abu

Thanks @TomF, this is really informative.

So today client cannot send nacks to the broker to pause the delivery to consumers, then I fail to understand the purpose of sending acks ?

Is it only to help the broker to decide when to issue redeliveries ?

TomF

Hi @Abu, a pleasure, always happy to help!

So today client cannot sent nacks to the broker

Yes correct...

to pause the delivery to consumers

Ooh - is that really what you want to do? That's different to a nack. A nack says "this message was not processed, it should be processed again." If you want to _pause_ delievery (for instance, to prevent your application being overwhelmed), you should call .stop() on the flow. This will do as it says, and when your application is ready again, call .start().

Is it only to help the broker to decide when to issue redeliveries ?

Yes... in a sense. The ack mechanism is there to tell the broker that you have _successfully processed the message_. The idea is that if your application crashes, it should be able to start again and pick up where it left off. If your application didn't finish with a message it should be redelivered as you said. It isn't a flow control mechanism, though, if that's what you meant. We do have a transport level ack scheme for transport level flow control, but what you're talking about is application level flow control, and that's where .stop and .start come in.

Abu

Hi,

Seems like I mixed the two with the word 'pause' :)

My question was only around sending NACKS by the consumer hoping for redeliveries. As already mentioned, we don't have the replay feature rolled-out as yet since the feature is not useful for a broker that is shared across different clients.

But thanks again, I got my answers now.