[ https://issues.apache.org/jira/browse/HBASE-28976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Wellington Chevreuil resolved HBASE-28976. ------------------------------------------ Resolution: Fixed Merged to master, branch-3, branch-2 and branch-2.6. > Fix UT flakeyness in TestBucketCache.testBlockAdditionWaitWhenCache and > TestVerifyBucketCacheFile.testRetrieveFromFile > ---------------------------------------------------------------------------------------------------------------------- > > Key: HBASE-28976 > URL: https://issues.apache.org/jira/browse/HBASE-28976 > Project: HBase > Issue Type: Bug > Affects Versions: 3.0.0-beta-1, 2.7.0, 2.6.1, 2.5.10 > Reporter: Wellington Chevreuil > Assignee: Wellington Chevreuil > Priority: Major > Labels: pull-request-available > Fix For: 3.0.0, 2.7.0, 2.6.2 > > > Noticed these two tests failing intermittently on some of the pre-commit > runs. > 1) TestBucketCache.testBlockAdditionWaitWhenCache: The test calls > BucketCache.cacheBlock() passing true to the waitWhenCache parameter, > assuming the cache call will wait for a success cache, however this is only > true if the BucketCache.QUEUE_ADDITION_WAIT_TIME property is also defined, so > I believe this may be causing the intermittent failures when the pre-commit > runs on slower vms. > > 2) TestVerifyBucketCacheFile.testRetrieveFromFile: One of the checks > performed by this test is to delete the bucket cache file, shutdown the > current BucketCache instance, then create a new BucketCache instance that > would load the persistent file but should fail to recover the cache, as the > cache file has been deleted. The way this recover works, internally, is > async. We first read the contents of the persistent file, which includes the > last serialized backingMap and a checksum of the cache file at that time. It > then compares this recovered checksum against the current cache file > checksum. If this verification fails, it starts a background thread to > traverse all backingMap entries and check if those entries are still > available in the cache. At this point, the test is ready to check the > BucketCache allocator size, expecting it to be 0, but if the background > verification has not finished yet, this assert will fail. -- This message was sent by Atlassian Jira (v8.20.10#820010)