HDDS-10103. Simplified snapshotCache with just one ConcurrentHashMap. #5986
Conversation
…dingEvictionList and ReferenceCountedCallback.
There was a problem hiding this comment.
Thanks for the patch @hemantk-12. The change overal looks very simple everything working under compute method of ConcurrentHashMap. We can look into optimizing the cleanup method to fetch the instances only with 0 references. This would be critical if the cache size is set to be high.
Similar point was raised by Siyao in #5968 (comment). It could be a follow up task. |
There was a problem hiding this comment.
LGTM+1. Thanks for the patch @hemantk-12 , just one comment inline. I'll close #5934 in accordance with this PR.
...-ozone/ozone-manager/src/main/java/org/apache/hadoop/ozone/om/snapshot/ReferenceCounted.java
Show resolved
Hide resolved
|
Thanks @aswinshakil, @swamirishi and @smengcl for the review. |
|
Follow up task HDDS-10156 to optimize the clean up. |
…rentHashMap. (apache#5986) (cherry picked from commit a8341d7) Change-Id: Iee0a0e72c73a1d19645655aebc24f4471a493cec (cherry picked from commit 57a443b27b12dfa71ba4fcd73b93cde97e86f010)
…apache#5986) (cherry picked from commit a8341d7)
What changes were proposed in this pull request?
Currently we use two different Concurrent collections, ConcurrentMap to keep entries in the cache and ConcurrentSet to keep track for the entries which can be closed. Usage of these two are causing deadlock and race condition problem.
In this change, usage of ConcurrentSet to keep track of closable entries is removed. Now we are iterating over the ConcurrentMap itself and checking if entry's reference size has reached zero and can be closed. If it has, we close the RocksDB object and remove the entry from the SnapshotCache.
What is the link to the Apache JIRA
HDDS-10103
How was this patch tested?
Existing unit and integration tests.