Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add delayed retry implementation #1

Closed

Conversation

alyosha
Copy link
Owner

@alyosha alyosha commented Jun 18, 2019

Summary

The aim of this change is to introduce a Pubsub-native means of delaying message retry, rather than simply holding the message outstanding, which is the only real means of accomplishing this at the moment. The changes discussed in this issue and introduced from version 0.19.0 were breaking for many people who were calling neither Ack nor Nack upon return from Receive as a means of implementing a rudimentary retry delay. This addition would allow them an alternative means of implementing the same functionality with more precision.

Calling Nack over and over is not an ideal solution for these cases. Good problem statement is seen in this comment on an issue thread in the Java library

Explanation of changes

  • This PR adds a new method Delay which can be called on a Message pointer receiver
  • The new method takes an argument of time.Duration, representing the desired period of time to wait before retrying delivery of the message
    • Example: msg.Delay(30*time.Second)
  • Calling Delay simply sets the unexported retryDelay delay field of the Message struct to the desired wait period
  • Upon return from Receive, the value of the message's retryDelay field is checked
    • If non-zero, the message is released from flow control and has its ackDeadline modified based on the provided retryDelay value
    • The retry value is capped at the maxAckDeadline value of 10 minutes, regardless of the provided duration
  • Because the delay duration is simply an argument, each client is free to implement their own backoff logic (with the caveat that it will be capped at 10m max)

Example use case for this new functionality:

  • A message is received which cannot be processed immediately
    • This message needs to be retried later, but it may take some time until subsequent attempts can be successfully processed
    • Rather than calling Nack repeatedly and having the message retry over and over, it would be preferable to delay the message retry by a certain period of time and only try again once that specified duration has passed.

Related issue threads

@alyosha alyosha closed this Jun 23, 2019
@alyosha alyosha deleted the delayed-retry-implementation branch June 23, 2019 05:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant