You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@geode.apache.org by "Owen Nichols (Jira)" <ji...@apache.org> on 2022/06/22 20:47:05 UTC

[jira] [Closed] (GEODE-9256) Remove hscan related fields from redis hash

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

Owen Nichols closed GEODE-9256.
-------------------------------

> Remove hscan related fields from redis hash
> -------------------------------------------
>
>                 Key: GEODE-9256
>                 URL: https://issues.apache.org/jira/browse/GEODE-9256
>             Project: Geode
>          Issue Type: Improvement
>          Components: redis
>            Reporter: Dan Smith
>            Assignee: Dan Smith
>            Priority: Major
>              Labels: pull-request-available
>             Fix For: 1.15.0
>
>
> To implement hscan it looks like we added a number of fields to every redis hash.
> {code}
>   private ConcurrentHashMap<UUID, List<ByteArrayWrapper>> hScanSnapShots;
>   private ConcurrentHashMap<UUID, Long> hScanSnapShotCreationTimes;
>   private ScheduledExecutorService HSCANSnapshotExpirationExecutor = null;
> {code}
> This greatly increases the per hash overhead of radish. We also create HSCANSnapshotExpirationExecutor for every hash that has an active hscan, potentially using a lot of threads.
> These fields should be removed from the hash itself so we are not increasing its overhead. If we need to maintain state related to hscan it should probably be in some client specific data structure like the ExecutionHandlerContext.
> Redis itself looks like it doesn't maintain any server side state. We should use the same stateless cursor algorithm as redis and avoid keeping any state on the server. Here's an article that goes in depth on the redis algorithm
> https://www.freecodecamp.org/news/redis-hash-table-scan-explained-537cc8bb9f52/



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