[
https://issues.apache.org/jira/browse/HBASE-13301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14381237#comment-14381237
]
zhangduo commented on HBASE-13301:
----------------------------------
[~ram_krish]
Yes, get and compare then remove is perfect. But it is not straight forward in
this case. We do have a IdLock, but it is only used in get and evict, and the
lock key is offset, not BlockCacheKey.
And my wonder is whether the error in this testcase could happen in real world.
Maybe the access pattern we use can avoid this error? I do not know...
Anyway, remove first then compare is not a good idea I think. If we can enter
the 'not equals' branch then no doubt, it is a bug. And if we never enter the
'not equals' branch, then why we need the compare...
Thanks.
> 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)
