jhungund commented on code in PR #5866:
URL: https://github.com/apache/hbase/pull/5866#discussion_r1601360335
##########
hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/bucket/BucketCache.java:
##########
@@ -2203,6 +2204,21 @@ public Optional<Boolean> shouldCacheFile(HFileInfo
hFileInfo, Configuration conf
return Optional.of(!fullyCachedFiles.containsKey(fileName));
}
+ @Override
+ public Optional<Boolean> shouldCacheBlock(BlockCacheKey key, Configuration
conf) {
+ try {
+ DataTieringManager dataTieringManager = DataTieringManager.getInstance();
+ if (dataTieringManager != null && !dataTieringManager.isHotData(key,
conf)) {
Review Comment:
The general idea behind storing any data in the memory (as BlockCacheKey
will reside in memory) is to use the data in future. Here, we are increasing
the size of BlockCacheKey, transiently using the newly added member for making
caching decisions, but later keeping the data in the BlockCacheKey without
using it for later. Additionally this increase in size is effective even if the
feature is not enabled, since we have changed the class layout.
Hence, the general idea about the new proposal is to store metadata in
BlockCacheKey, which will not be used later at all. Instead, store it on the
stack (member variable) so that the variable will go away after getting used.
You can use the APIs accordingly.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@hbase.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
