Skip to content

Fixed Tracking test “The other connection is able to get invalidations”#7871

Merged
oranagra merged 1 commit intoredis:unstablefrom
nitaicaro:fix-invalidation-test
Sep 30, 2020
Merged

Fixed Tracking test “The other connection is able to get invalidations”#7871
oranagra merged 1 commit intoredis:unstablefrom
nitaicaro:fix-invalidation-test

Conversation

@nitaicaro
Copy link
Contributor

PROBLEM:

[$rd1 read] reads invalidation messages one by one, so it's never going to see the second invalidation message produced after INCR b, whether or not it exists. Adding another read will block incase no invalidation message is produced.

FIX:

We switch the order of "INCR a" and "INCR b" - now "INCR b" comes first. We still only read the first invalidation message produces. If an invalidation message is wrongly produces for b - then it will be produced before that of a, since "INCR b" comes before "INCR a".

PROBLEM:

[$rd1 read] reads invalidation messages one by one, so it's never going to see the second invalidation message produced after INCR b, whether or not it exists. Adding another read will block incase no invalidation message is produced.

FIX:

We switch the order of "INCR a" and "INCR b" - now "INCR b" comes first. We still only read the first invalidation message produces. If an invalidation message is wrongly produces for b - then it will be produced before that of a, since "INCR b" comes before "INCR a".
@oranagra oranagra merged commit 8fb89a5 into redis:unstable Sep 30, 2020
@oranagra
Copy link
Member

thanks.

oranagra pushed a commit that referenced this pull request Oct 27, 2020
…s” (#7871)

PROBLEM:

[$rd1 read] reads invalidation messages one by one, so it's never going to see the second invalidation message produced after INCR b, whether or not it exists. Adding another read will block incase no invalidation message is produced.

FIX:

We switch the order of "INCR a" and "INCR b" - now "INCR b" comes first. We still only read the first invalidation message produces. If an invalidation message is wrongly produces for b - then it will be produced before that of a, since "INCR b" comes before "INCR a".

Co-authored-by: Nitai Caro <[email protected]>
(cherry picked from commit 8fb89a5)
JackieXie168 pushed a commit to JackieXie168/redis that referenced this pull request Nov 4, 2020
…s” (redis#7871)

PROBLEM:

[$rd1 read] reads invalidation messages one by one, so it's never going to see the second invalidation message produced after INCR b, whether or not it exists. Adding another read will block incase no invalidation message is produced.

FIX:

We switch the order of "INCR a" and "INCR b" - now "INCR b" comes first. We still only read the first invalidation message produces. If an invalidation message is wrongly produces for b - then it will be produced before that of a, since "INCR b" comes before "INCR a".

Co-authored-by: Nitai Caro <[email protected]>
jschmieg pushed a commit to memKeyDB/memKeyDB that referenced this pull request Nov 6, 2020
…s” (redis#7871)

PROBLEM:

[$rd1 read] reads invalidation messages one by one, so it's never going to see the second invalidation message produced after INCR b, whether or not it exists. Adding another read will block incase no invalidation message is produced.

FIX:

We switch the order of "INCR a" and "INCR b" - now "INCR b" comes first. We still only read the first invalidation message produces. If an invalidation message is wrongly produces for b - then it will be produced before that of a, since "INCR b" comes before "INCR a".

Co-authored-by: Nitai Caro <[email protected]>
(cherry picked from commit 8fb89a5)
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.

2 participants