[
https://issues.apache.org/jira/browse/HBASE-21426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16883633#comment-16883633
]
Xiaolin Ha commented on HBASE-21426:
------------------------------------
The UT failed at check pathsAfterCompaction,
{code:java}
for (Path path: pathsAfterCompaction) {
assertTrue("Store file " + path + " has incorrect key",
Bytes.equals(secondCFKey.getEncoded(), extractHFileKey(path)));
}
{code}
The reason is that, the method `waitForCompaction` it used to check if major
compaction is completed is wrong.
After called majorCompact, the UT first used findCompactedStorefilePaths to
ensure there is no compacted store files, and then it used store file count ==
1 && store file is not marked compactedAway to judge the complement of major
compaction.
But because the table only flushed one store file before, and the default value
of compactedAway of store files is false, even if major compaction is not
completed or not started, the method will still return and tells that the major
compaction is completed.
> TestEncryptionKeyRotation.testCFKeyRotation is flakey
> -----------------------------------------------------
>
> Key: HBASE-21426
> URL: https://issues.apache.org/jira/browse/HBASE-21426
> Project: HBase
> Issue Type: Bug
> Reporter: Xiaolin Ha
> Assignee: Xiaolin Ha
> Priority: Major
> Attachments: testCFKeyRotation [Jenkins test result].pdf
>
>
> waitForCompaction() does not work for checking major compact completion in
> this case.
> {code:java}
> // Verify we have store file(s) with only the new key
> Thread.sleep(1000);
> waitForCompaction(htd.getTableName());
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
