1

As the maximum duration for the retention of an 'undelivered' message is 7 days, I am curious as to what a NACK does as regards keeping the message 'alive'.

For example, if I NACK a message one day before its expiry does it get a fresh lease of 7 days before it's dropped, or does it die the next day itself?

I am unsure of of how to interpret the language of this documentation as a NACKed message technically hasn't failed to deliver, but has been refused by the Subscriber.

Angad
  • 2,803
  • 3
  • 32
  • 45

1 Answers1

2

"Delivered" in this context would mean "Google Cloud Pub/Sub sent the message to the subscriber and that subscriber acknowledged the message." It would be like when UPS requires a signature for a package: the package is delivered when you sign for it and take it, not when they knock on your door and you don't answer (or perhaps nack would be equivalent to you saying "go away, I'm not coming to the door").

The 7 day retention policy is from the time the message is published. The clock does not reset if a message is acked. If the subscriber receives a message a day before its expiry time and nacks it, redelivery would only be attempted for one more day, not for seven additional days.

Kamal Aboul-Hosn
  • 15,111
  • 1
  • 34
  • 46
  • Thanks Kamal - is there any reliable way to evacuating these messages before they are deleted? I'm not looking for a Dead-Letter Channel but some way for it to be triggered seems essential. Alternatively if there was a way to drip a BigQuery collection into a Topic at a 'safe' consumption rate... – Angad Apr 11 '19 at 18:19
  • There is currently no way to do anything with messages that are about to be deleted, no. With the section part of your question, do you mean that you need to send data from BigQuery into Pub/Sub at a rate at which your subscribers are able to handle it? Are your subscribers getting overwhelmed and that is what is leading you to nack messages? – Kamal Aboul-Hosn Apr 11 '19 at 18:28
  • The challenge is more because of customer-defined rate-limiting - I don't want to get into managing a RabbitMQ or Kafka cluster just for dead-letter based scheduling, but often have to NACK messages for a few minutes to an hour to delay them (this is a solution I found here https://stackoverflow.com/a/42956435/382564 that I am reluctantly considering as a feasible solution). It is the rate of this buildup I am attempting to grasp, ideally preparing for it with a pure-GCP solution – Angad Apr 11 '19 at 18:33
  • 1
    Yeah, Cloud Pub/Sub does not offer finer-grained control over the retry semantics when a message is nacked at this time. Nacking a message will make it a candidate for immediate redelivery. You could buffer the messages and process them at the desired time and only ack them after that (though you risk redelivery happening the longer messages are outstanding). There could also be implications for memory consumption by the subscriber if you do this. – Kamal Aboul-Hosn Apr 11 '19 at 19:12