[
https://issues.apache.org/jira/browse/HBASE-29183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wellington Chevreuil resolved HBASE-29183.
------------------------------------------
Resolution: Fixed
Merged to master, branch-3, branch-2 and branch-2.6. Thanks for reviewing it,
[~zhangduo] !
> Fix flakeyness on TestVerifyBucketCacheFile
> -------------------------------------------
>
> Key: HBASE-29183
> URL: https://issues.apache.org/jira/browse/HBASE-29183
> Project: HBase
> Issue Type: Bug
> Affects Versions: 3.0.0-beta-1, 4.0.0-alpha-1, 2.7.0, 2.6.2
> Reporter: Wellington Chevreuil
> Assignee: Wellington Chevreuil
> Priority: Major
> Labels: pull-request-available
> Fix For: 3.0.0, 4.0.0-alpha-1, 2.7.0, 2.6.3
>
>
> I've noticed some flakeyness in some of the tests from
> TestVerifyBucketCacheFile. One of the latest intermittent failures I've found
> on the precommit run for a PR:
> {noformat}
> java.lang.AssertionError: expected:<0> but was:<17408>
> at org.junit.Assert.fail(Assert.java:89)
> at org.junit.Assert.failNotEquals(Assert.java:835)
> at org.junit.Assert.assertEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:633)
> at
> org.apache.hadoop.hbase.io.hfile.bucket.TestVerifyBucketCacheFile.testModifiedBucketCacheFileData(TestVerifyBucketCacheFile.java:247)
> {noformat}
> These are quite hard to reproduce locally, but after analysing the test code
> and the stack trace, I believe this might be related to the changes from
> HBASE-28900, which allowed BucketAllocator to complete initialisation with a
> partially recovered cache, requiring the backingMap validation to complete,
> in order to get rid of entries with inconsistent checksums.
> The solution for such tests that deal with persistent cache recover is to put
> an extra wait for the backingMap validation to be complete, before starting
> checking on the expected bucket cache size/usage.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
