[
https://issues.apache.org/jira/browse/HBASE-26094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yutong Xiao updated HBASE-26094:
--------------------------------
Description:
Currently in branch-1, the block cache initialisation is as this code:
{code:java}
LruBlockCache l1 = getL1(conf);
// blockCacheDisabled is set as a side-effect of getL1Internal(), so check
it again after the call.
if (blockCacheDisabled) return null;
BlockCache l2 = getL2(conf);
if (l2 == null) {
GLOBAL_BLOCK_CACHE_INSTANCE = l1;
} else {
boolean useExternal = conf.getBoolean(EXTERNAL_BLOCKCACHE_KEY,
EXTERNAL_BLOCKCACHE_DEFAULT);
boolean combinedWithLru = conf.getBoolean(BUCKET_CACHE_COMBINED_KEY,
DEFAULT_BUCKET_CACHE_COMBINED);
if (useExternal) {
GLOBAL_BLOCK_CACHE_INSTANCE = new InclusiveCombinedBlockCache(l1, l2);
} else {
if (combinedWithLru) {
GLOBAL_BLOCK_CACHE_INSTANCE = new CombinedBlockCache(l1, l2);
} else {
// L1 and L2 are not 'combined'. They are connected via the
LruBlockCache victimhandler
// mechanism. It is a little ugly but works according to the
following: when the
// background eviction thread runs, blocks evicted from L1 will go to
L2 AND when we get
// a block from the L1 cache, if not in L1, we will search L2.
GLOBAL_BLOCK_CACHE_INSTANCE = l1;
}
}
l1.setVictimCache(l2);
}
{code}
As the code above, L2 will always be the victimhandler of L1, no matter if we
use combined blockcache or not. But as logic (in master & branch-2) L2 should
not be the victimhandler of L1 when using combined BC. We should set the
victimhandler only when we use InclusiveConbinedBC or we do not use CombinedBC.
was:As the logic, the L2 should not be the victimhandler of L1 cache. When
using InclusiveCombinedBlockCache, we should set L2 as the victimhandler of L1.
> In branch-1 L2 BC should not be the victimhandler of L1 BC when using
> combined BC
> ---------------------------------------------------------------------------------
>
> Key: HBASE-26094
> URL: https://issues.apache.org/jira/browse/HBASE-26094
> Project: HBase
> Issue Type: Bug
> Components: BlockCache
> Affects Versions: 1.7.0
> Reporter: Yutong Xiao
> Assignee: Yutong Xiao
> Priority: Major
>
> Currently in branch-1, the block cache initialisation is as this code:
> {code:java}
> LruBlockCache l1 = getL1(conf);
> // blockCacheDisabled is set as a side-effect of getL1Internal(), so
> check it again after the call.
> if (blockCacheDisabled) return null;
> BlockCache l2 = getL2(conf);
> if (l2 == null) {
> GLOBAL_BLOCK_CACHE_INSTANCE = l1;
> } else {
> boolean useExternal = conf.getBoolean(EXTERNAL_BLOCKCACHE_KEY,
> EXTERNAL_BLOCKCACHE_DEFAULT);
> boolean combinedWithLru = conf.getBoolean(BUCKET_CACHE_COMBINED_KEY,
> DEFAULT_BUCKET_CACHE_COMBINED);
> if (useExternal) {
> GLOBAL_BLOCK_CACHE_INSTANCE = new InclusiveCombinedBlockCache(l1, l2);
> } else {
> if (combinedWithLru) {
> GLOBAL_BLOCK_CACHE_INSTANCE = new CombinedBlockCache(l1, l2);
> } else {
> // L1 and L2 are not 'combined'. They are connected via the
> LruBlockCache victimhandler
> // mechanism. It is a little ugly but works according to the
> following: when the
> // background eviction thread runs, blocks evicted from L1 will go
> to L2 AND when we get
> // a block from the L1 cache, if not in L1, we will search L2.
> GLOBAL_BLOCK_CACHE_INSTANCE = l1;
> }
> }
> l1.setVictimCache(l2);
> }
> {code}
> As the code above, L2 will always be the victimhandler of L1, no matter if we
> use combined blockcache or not. But as logic (in master & branch-2) L2 should
> not be the victimhandler of L1 when using combined BC. We should set the
> victimhandler only when we use InclusiveConbinedBC or we do not use
> CombinedBC.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
