Server may redeliver a message that has just been acknoweldged #1138
Assignees
Labels
Comments
kozlovic
added a commit
that referenced
this issue
Jan 8, 2021
During redelivery, a go routine gathers all pending messages under a lock. However, the actual send of messages is done one by one and by then, one of the message in the list of messages to redeliver may have been acknowledged. So during the send, under the sub's lock, we need to check that if a message marked as redelivered is no longer in the pending list, it should not be sent to the client. Also fixed an unrelated data race that was just found running tests. Resolves #1138 Signed-off-by: Ivan Kozlovic <ivan@synadia.com>
kozlovic
added a commit
that referenced
this issue
Jan 8, 2021
During redelivery, a go routine gathers all pending messages under a lock. However, the actual send of messages is done one by one and by then, one of the message in the list of messages to redeliver may have been acknowledged. So during the send, under the sub's lock, we need to check that if a message marked as redelivered is no longer in the pending list, it should not be sent to the client. Also fixed an unrelated data race that was just found running tests. Resolves #1138 Signed-off-by: Ivan Kozlovic <ivan@synadia.com>
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Normally, applications should acknowledge all messages that they receive, even if it is a redelivered message.
But if an application keeps track of which message the application has acknowledged and never call Ack() again on the same message, and if a race happens in the server, a message may be redelivered and added to the pending list and will always be redelivered.
Again, this would be a problem only for applications that use manual ack mode and do not ack a redelivered message that it believes has already been acknowledged.
The text was updated successfully, but these errors were encountered: