[
https://issues.apache.org/jira/browse/GEODE-10171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515625#comment-17515625
]
ASF subversion and git services commented on GEODE-10171:
---------------------------------------------------------
Commit fb17fe41adb877aabd96aa4fc95509c4b652dc0b in geode's branch
refs/heads/develop from Kris10
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=fb17fe4 ]
GEODE-10171: Update versioning for no-op operations (#7527)
Modified lrem to not update versioning if nothing was removed from the
list.
> AbstractRedisData version being incremented for no-op operations can lead to
> delta not being applied on secondary
> -----------------------------------------------------------------------------------------------------------------
>
> Key: GEODE-10171
> URL: https://issues.apache.org/jira/browse/GEODE-10171
> Project: Geode
> Issue Type: Bug
> Components: redis
> Affects Versions: 1.15.0
> Reporter: Donal Evans
> Assignee: Kristen
> Priority: Major
> Labels: blocks-1.15.0, pull-request-available
>
> For SADD, which may or may not modify the data in the region depending on
> whether the member being added is already present in the set, the version in
> AbstractRedisData is updated regardless of whether a Delta is sent to the
> secondary. This can lead to the version on the primary wrapping around to be
> equal to the version on the secondary, which means that if a delta is sent,
> it will not be applied on the secondary, leading to potential data loss.
> Below is a test to show this behaviour:
> {code:java}
> @Test
> public void deltaVersionOnPrimary_shouldNotUpdate_ifNoDeltaSent() {
> String originalMember = "fixedMemberName";
> String key = clusterStartUp.getKeyOnServer("tag", 1);
>
> // Version of primary = 0
> // Version of secondary = 0
> jedis.sadd(key, originalMember);
> // No changes are made to the set, since adding an already existing member
> doesn't modify it
> // Version of primary wraps around back to -1
> // Version of secondary doesn't change because we don't send a delta
> for (int i = 0; i < 255; ++i) {
> jedis.sadd(key, originalMember);
> }
> String newMember = "aNewMemberName";
> // Version of primary = 0
> // Version of secondary = 0, delta is not applied
> jedis.sadd(key, newMember);
> assertThat(jedis.smembers(key)).containsExactlyInAnyOrder(originalMember,
> newMember);
> clusterStartUp.crashVM(1); // kill primary server
> assertThat(jedis.smembers(key)).containsExactlyInAnyOrder(originalMember,
> newMember);
> } {code}
> The example here uses SADD, but potentially, any command that can be a no-op
> and uses a versioned Delta is at risk of hitting this. All commands should be
> checked to ensure they're not vulnerable to this bug.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
