-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
test ackDeadline #3394
test ackDeadline #3394
Conversation
I think this is mostly expected. The client library will automatically extend (modack) the messages that hasn't been acked or nacked. So not getting the message again is more like a sign that automatic deadline extension is working. By default, the client will auto-extend messages for an hour. You can change this with |
@pongad What was the reasoning behind introducing such a long default ack extension? It doesn't even seem to be documented anywhere, whereas it radically changes the expectations of the users of how the ack deadline works. |
@garrettjonesgoogle Friendly ping. |
@pongad should take a look at your question first I think |
Sorry I missed this earlier. I believe this was recommended by Pubsub team a long time ago. @kir-titievsky do you happen to know? I'll make a PR to document this. @meltsufin @dmitry-s Could you tell us what kind of problem this is causing you? I believe you're the first people who want to see duplicates. |
@pongad sorry, don't remember any more. I'm assuming the idea was to reduce duplicate deliveries. |
@pongad The main issue with this behavior is the element of surprise to the users who don't expect the ack deadline to be auto-extended for an hour by default. In the least, this needs to be documented. |
The behavior is now documented. I'll close this for now, but please let us know if there's still confusion. |
@pongad Link(s)? |
It should be in the client doc. Search for "ack management". |
This test reproduces an issue with ackDeadline. It publishes 2 messages, then it pools them and nacks one of them. The other one is not being nacked or acked. Then it tries to pull both messages again, in a loop.
The ackDeadline is set to 10 seconds, so I would expect to get both messages after that time. But the message that wasn't nacked or acked never makes it back.
What is interesting, if I enable debugging and put a break point inside the loop, I am able to get both messages.
I verified that ackDeadline works as expected in gcloud cli tool.