[
https://issues.apache.org/jira/browse/GEODE-9772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17454771#comment-17454771
]
ASF subversion and git services commented on GEODE-9772:
--------------------------------------------------------
Commit ee1471f30d0e275fefbc7af3cba7c7e596541620 in geode's branch
refs/heads/develop from Darrel Schneider
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=ee1471f ]
GEODE-9772: use delta for all redis modify data ops (#7105)
-- Now a delta is sent even if the entire RedisData value is being changed.
The only exception to this is if a geode transaction is in progress in which
case delta can not be used.
-- the classes that implement DeltaInfo now have a more uniform naming scheme
that is consistent with the DeltaType enum and the apply*Delta methods.
-- Also each class that implements DeltaInfo now has a static deserializeFrom
that takes care of reading off the DataInput all the bytes written by
serializeTo.
This has the advantage of having the serialization and corresponding
deserialization
code in the same class.
-- removed the sequence number of RedisString which existed for append when it
might have been done twice due to geode retrying the function execution.
Now, because of cluster mode, append no longer uses a geode function so the
sequence number is no longer needed.
> 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.1#820001)
