Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Thu, 14 Dec 2017 09:59:00 +0000 (UTC)
From: "Anoop Sam John (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.13124874.1513229397000.456675.1513245540485@Atlassian.JIRA>
In-Reply-To: <JIRA.13124874.1513229397000@Atlassian.JIRA>
References: <JIRA.13124874.1513229397000@Atlassian.JIRA> <JIRA.13124874.1513229397032@jira-lw-us.apache.org>
Subject: [jira] [Commented] (HBASE-19511) Splits causes blocks to be cached
 again and so such blocks cannot be evicted from bucket cache
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Thu, 14 Dec 2017 09:59:04 -0000


    [ https://issues.apache.org/jira/browse/HBASE-19511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16290636#comment-16290636 ] 

Anoop Sam John commented on HBASE-19511:
----------------------------------------

+1 

> Splits causes blocks to be cached again and so such blocks cannot be evicted from bucket cache
> ----------------------------------------------------------------------------------------------
>
>                 Key: HBASE-19511
>                 URL: https://issues.apache.org/jira/browse/HBASE-19511
>             Project: HBase
>          Issue Type: Bug
>          Components: BucketCache
>    Affects Versions: 2.0.0-alpha-4
>            Reporter: ramkrishna.s.vasudevan
>            Assignee: ramkrishna.s.vasudevan
>            Priority: Critical
>             Fix For: 3.0.0, 2.0.0-beta-1
>
>         Attachments: HBASE-19511.patch, HBASE-19511_1.patch
>
>
> This is because of similar pattern as in 
> https://issues.apache.org/jira/browse/HBASE-8547.
> It took a lot of time to debug this and the reason for TestBlockeEvictionFromClient was flaky due to this. 
> When we create split files the index of the firstKey that we create could possibly be the same key as in the case of #testBlockRefCountAfterSplits().
> In such cases we were getting the same block to be cached again in the bucket cache. As part of HBASE-8547 such cases were being handled. 
> {code}
> String msg = "Caching an already cached block: " + cacheKey;
>        msg += ". This is harmless and can happen in rare cases (see HBASE-8547)";
>        LOG.warn(msg);
> {code}
> But this is a tricky case where this log msg will be coming only when block with same cachekey was completely cached in the bucket cache. If there is a case where the block with the same cachekey was not yet completed written to bucket cache (by cache writer threads) this this log msg won't come but the ramCache key wil prevent the block from again getting cached.
> {code}
>     if (ramCache.putIfAbsent(cacheKey, re) != null) {
>       return;
>     }
> {code}
> So when ever the block was getting cached once again and it is already in backingMap then we were doing a getBlock() to verify if the block is the same block. This was internallly adding to the refcount and so those blocks will never get removed from the bucket cache queue. ( there is no one to decrement the ref count on such cases). 
> So I think for this rare cases it is better we do a copy of the block and then check if the block is same as the existing one. This should be harmless and should help us in doing proper ref counting 


--
This message was sent by Atlassian JIRA
(v6.4.14#64029)