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

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: