Open turneand opened 3 months ago
Unfortunately my workaround is not correct, as have observed these errors, and therefore the associated duplicate messages even when the maxOutstandingElementCount is null, or 0.
I was able to reproduce the INVALID_ARGUMENT: Some acknowledgement ids in the request were sent out of order
errors which seem to occur because of multiple outstanding acknowledgement requests. We are still investigating this issue, but as a current workaround, you can utilize the acknowledgement with response interface when receiving messages. Following the SubscribeWithExactlyOnceConsumerWithResponse
sample will allow you to check the response of your acknowledgement call for each message. This will prevent multiple outstanding acknowledgement requests by only processing the next message once the previous message has been successfully acknowledged, although it may slow down message processing.
Environment details
Steps to reproduce
This is similar steps as in https://github.com/googleapis/java-pubsub/issues/1889
A workaround we have is to set the "maxOutstandingElementCount" down to 1, which appears to effectively disable any batching. Although our application can handle a certain degree of instability with pubsub, the extent we get these (hundreds per day) is excessive.
Code example
Note, this seems to be a race condition, I've managed to get the following to reproduce the issues consistently, but not 100% guranteed. On some executions, only a couple of errors get logged, but on others I get hundreds.
In our live applications, we get this when sending acks or nacks, which causes significant delays as we have to wait for the default timeouts to occur before it will attempt again.
Stack trace
External references such as API reference guides
Any additional information below
This is similar to https://github.com/googleapis/java-pubsub/issues/1889
Following these steps guarantees the quickest resolution possible.
Thanks!