[
https://issues.apache.org/jira/browse/HBASE-13301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14383753#comment-14383753
]
Anoop Sam John commented on HBASE-13301:
----------------------------------------
{quote}
t1 cache a block
t2 evict the block but stopped before acquiring offsetLock(this is done by
holding the offsetLock with t1 in this testcase)
t1 evict the block, and cache the block again.
t2 continue evicting the block...
{quote}
Seems this won't happen in real scenarios...
But any was as you said above, it looks a buggy.. Better we can change to get
compare and remove.. The evict op is not in a hot code path. So no issue is
doing and extra op. A get for the same block will have to wait a bit more and
any way it is not going to see the block and have to fetch from DFS.
Considering that time, this extra bit of time is nothing. Good to fix as Ram
suggested.
> Possible memory leak in BucketCache
> -----------------------------------
>
> Key: HBASE-13301
> URL: https://issues.apache.org/jira/browse/HBASE-13301
> Project: HBase
> Issue Type: Bug
> Components: BlockCache
> Reporter: zhangduo
> Assignee: zhangduo
> Attachments: HBASE-13301-testcase.patch
>
>
> {code:title=BucketCache.java}
> public boolean evictBlock(BlockCacheKey cacheKey) {
> ...
> if (bucketEntry.equals(backingMap.remove(cacheKey))) {
> bucketAllocator.freeBlock(bucketEntry.offset());
> realCacheSize.addAndGet(-1 * bucketEntry.getLength());
> blocksByHFile.remove(cacheKey.getHfileName(), cacheKey);
> if (removedBlock == null) {
> this.blockNumber.decrementAndGet();
> }
> } else {
> return false;
> }
> ...
> {code}
> I think the problem is here. We remove a BucketEntry that should not be
> removed by us, but we do not put it back and also do not do any clean up.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
