[
https://issues.apache.org/jira/browse/HBASE-20447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16444652#comment-16444652
]
Andrew Purtell commented on HBASE-20447:
----------------------------------------
The "Cached an already cached block .. This is harmless" log line should be
DEBUG level I think. I have this patched as such internally. Otherwise the
warnings concern operators without being actionable. So in your patch where you
have introduced more WARN level logs where the comparison differs by
nextBlockOnDiskSize the same thing applies I think.
Otherwise lgtm
> Only fail cacheBlock if block collisions aren't related to next block metadata
> ------------------------------------------------------------------------------
>
> Key: HBASE-20447
> URL: https://issues.apache.org/jira/browse/HBASE-20447
> Project: HBase
> Issue Type: Bug
> Components: BlockCache, BucketCache
> Affects Versions: 1.4.3, 2.0.0
> Reporter: Zach York
> Assignee: Zach York
> Priority: Major
> Fix For: 3.0.0, 2.1.0, 1.5.0, 1.4.4, 2.0.1
>
> Attachments: HBASE-20447.branch-1.001.patch,
> HBASE-20447.master.001.patch
>
>
> This is the issue I was originally having here:
> [http://mail-archives.apache.org/mod_mbox/hbase-dev/201802.mbox/%3CCAN+qs_Pav=md_aoj4xji+kcnetubg2xou2ntxv1g6m8-5vn...@mail.gmail.com%3E]
>
> When we pread, we don't force the read to read all of the next block header.
> However, when we get into a race condition where two opener threads try to
> cache the same block and one thread read all of the next block header and the
> other one didn't, it will fail the open process. This is especially important
> in a splitting case where it will potentially fail the split process.
> Instead, in the caches, we should only fail if the required blocks are
> different.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
