[jira] [Closed] (GEODE-9772) RedisString should consistently use a DeltaInfo for all write ops that update a RedisString

["Owen Nichols (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/GEODE-9772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Owen Nichols closed GEODE-9772.
-------------------------------

> RedisString should consistently use a DeltaInfo for all write ops that update a RedisString
> -------------------------------------------------------------------------------------------
>
>                 Key: GEODE-9772
>                 URL: https://issues.apache.org/jira/browse/GEODE-9772
>             Project: Geode
>          Issue Type: Improvement
>          Components: redis
>    Affects Versions: 1.15.0
>            Reporter: Darrel Schneider
>            Assignee: Darrel Schneider
>            Priority: Major
>              Labels: pull-request-available, release-blocker
>             Fix For: 1.15.0
>
>
> Currently RedisString generates a DeltaInfo instance when it does an "append" to an existing RedisString. But for all the other write ops on RedisString the implementation does not generate a DeltaInfo instance. This causes the entire RedisString instance to be serialized to the secondary. But the ops that do this tend to change the entire string (for example "set" get rid of the old value of the string and adds a brand new value). But even for these types of ops being consistent about generating a DeltaInfo has the following benefits:
> 1. the memory usage on the region will be consistent between the primary and secondary because the value will be stored in the same form on both of them. Understand that for value classes that implement the Delta interface (which all RedisData classes do) the primary will always store the value in deserialized form. But it gets stored on the secondary in serialized from until a value arrives on the secondary that is just the delta bytes. By generating a DeltaInfo instance the secondary will receive data bytes.
> 2. By keeping the values stored in the region in object form it causes updates to not produce "old garbage". What happens when a DeltaInfo is sent is that it modifies in place an object that is already in the JVM heap memory. But without a DeltaInfo a whole new value is created and the old value becomes garbage. That old value may have already been promoted to the older generation and now the JVM may have to do more work to get it garbage collected. It is best if object die young (sad but true).
> RedisString has a number of ops that do not use generate a DeltaInfo. But they could easily be changed to just generate a DeltaInfo that contains a byte array that is the new value of the RedisString. This would even work for "setrange" and "setbit" but those could be further optimized to only add a subset of the bytes to the DeltaInfo along with an index.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)