[FIXED] Clustering: possible wrong pending count #1220
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a regression introduced by PR #1213 which is in v0.23.0
(the latest release).
When a queue subscription left the group and its last_sent was the
same than the group's last_sent, the remaining queue member should
have its last_sent updated. To do that, the replication of a "sent"
event for this sequence was issued, which was wrong since it would
possibly add a pending on the remaining queue sub. Moreover, this
did not account for last_sent being 0, which with the aforementioned
behavior, a "sent" of sequence 0 would be replicated causing the
remaining queue sub to show a pending_count of 1.
The fix for both wrong pending_count and original last_sent issue
is to have all nodes (leader and followers) detect that when a
member is removed, if that member's last_sent value was the one
of the queue group, then update the runtime version of the remaining
queue member.
Signed-off-by: Ivan Kozlovic ivan@synadia.com