Message Ordering with Retry and NACK (how does it work)

Robert

In this page it states that message ordering is guaranteed when using guaranteed delivery:
https://docs.solace.com/Messaging/Guaranteed-Msg/Guaranteed-Messages.htm

I understand that it either would work when:

• Using exclusive queues
• Using non exclusive but partioned queues

It would not work:

• Push Subscription (RDP)
• Non Exclusive Queues (without partition)

I would like to understand how certain scenarios get handled in such a case ?

• You send back a NACK for one message ? Would the entire flow be then on hold ?

Aaron

Hi @Robert. Ordering should be maintained with RDPs, if you change the number of outgoing connections to 1 per REST Consumer.

Anyhow, I've recently been playing with some JCSMP code, testing message ordering and NACKs, so this is timely. Short answer: yes message ordering can change when doing a settle() with an Outcome of FAILED. The only way it cannot is if you set the queue's "max unacked messages per flow" to 1. Otherwise, there will be other messages pulled down off the queue, and when you NACK one message, the next one will be given to the client application before the NACK goes up to the broker and the message resent back down to the consumer.

vpandey

Hi @Aaron,

I am working with a scenario where a publisher is sending a large volume of guaranteed messages (50k messages/second) with a payload of 300 bytes each. If publisher successfully sent 1 million messages, but received a NACK (negative acknowledgment) for one message during transmission.

Details:

• API: Solace C API (latest)
• Broker: Solace Appliance (N-1)

I have the following queries:

1. Besides a full queue, under what other conditions does the broker send a NACK?
2. If a NACK is received and the spool clears after a few seconds, will the Solace C API automatically resend the message from the publisher's side?
3. Does the publisher application need to maintain a correlation tag or an acknowledgment queue for tracking message status?
4. Upon receiving a NACK, how does the Solace C API handle it? Does it require any action from the publisher application?
   5. What are solace document pages or discussion that can help me for this case?

Aaron

Hey @vpandey, so we're talking Guaranteed publishing here, not consuming as the original question above. This probably belongs in its own/new thread. Although, I guess the thread title matches up.

1. Besides full queue? Um: publish ACL violation; queue is shutdown (at least ingress shutdown) and is configured "reject to sender on discard including when shutdown" to true; Message VPN spool is full (even if queue is not); broker spool is full; maybe if doing sync-DR (Replication) and the remote DR brokers send NACK. Not sure if that's exhaustive, but what I can think of top of my head.
2. No, API will automatically resend for things like publish timeouts (didn't get ACK from broker in time), network interruptions, broker failovers, after reconnecting, but API will not automatically resend for NACKs received… that is "business logic" as to how the application wants to handle that scenario (i.e. try to resend? just log error? publish somewhere else? etc.). Publishing applicaiton has responsibility to keep published messages (and don't reset() after publishing) until the ACKs have been received.
3. Yes.
4. API doesn't do anything except trigger callback indicating publisher exception… hopefully you have your correlation key configured so you know which message it's for. Up to publisher now to figure out how to proceed.
5. I'm not sure… probably spread around in:

• https://docs.solace.com/API/API-Developer-Guide/Developer-Guide-Home.htm
• https://docs.solace.com/API-Developer-Online-Ref-Documentation/c/index.html
• Solace training
• Blogs, and posts here on Community

vpandey

Thanks @Aaron for quick response.
I will check and share my observations.