New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HBASE-21426 TestEncryptionKeyRotation.testCFKeyRotation is flaky #375
Conversation
return !found; | ||
public boolean evaluate() throws IOException { | ||
return TEST_UTIL.getAdmin().getCompactionState(htd.getTableName()) == | ||
CompactionState.NONE; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So here you are checking table's compaction state is "NONE" to determine compaction is done.
How is this sufficient? Can this state never changed? Thanks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi, @xcangCRM , thanks your questions.
How is this sufficient? Can this state never changed?
We all know majorCompact() is a async method, returning not means compaction completed.
But the method will return after building the compaction context and adding the compaction to the executor pool. And before the executor runs compaction, when building the compaction context, state of table regions that want to compact will be set to MAJOR by calling reportCompactionRequestStart(). So calling majorCompact() returns means table compaction state is not 'NONE' until the major compaction is completed.
💔 -1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
@@ -91,6 +92,7 @@ public static void setUp() throws Exception { | |||
conf.setInt("hfile.format.version", 3); | |||
conf.set(HConstants.CRYPTO_KEYPROVIDER_CONF_KEY, KeyProviderForTesting.class.getName()); | |||
conf.set(HConstants.CRYPTO_MASTERKEY_NAME_CONF_KEY, "hbase"); | |||
conf.setInt("hbase.hfile.compaction.discharger.interval", 10 * 60 * 1000); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why this config change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@infraio Thanks for reviewing.
Why this config change?
I changed this to let the compacted files be cleaned up slower than normal(10min instead of 2min). Because when I run testCFKeyRotation() for 100 times, I have met assertion fail at List<Path> compactedPaths = findCompactedStorefilePaths(htd.getTableName()); assertTrue(compactedPaths.size() > 0);
. So this test case may also be flaky at this assertion.
Enlarging the compaction discharger interval can ensure compacted files still be there after major compaction is completed but compacted paths are not checked in testCFKeyRotation().
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about a bigger value? The test will timeout if it can't finished after 780 seconds. So may be use 30 * 60 * 1000 is better which is bigger than 2 * 780?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I checked the test class config, it's a MediumTests.class, which will complete in 50 seconds. So the test method testCFKeyRotation() must complete in 50 secs, less than the cleaner interval(2 mins). I met this problem because when I ran 100 times of the method, I used parameterized running. All 100 cases used the same minicluster and when ran after 2 mins the case may met with checking compacted files fail.
@infraio I will convert the change of the conf.
💔 -1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
Signed-off-by: Guanghao Zhang <zghao@apache.org>
Signed-off-by: Guanghao Zhang <zghao@apache.org>
…che#375) Signed-off-by: Guanghao Zhang <zghao@apache.org>
No description provided.