[
https://issues.apache.org/jira/browse/HBASE-26674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17477623#comment-17477623
]
Duo Zhang commented on HBASE-26674:
-----------------------------------
OK, so in the old implementation, we hold the writeLock while updating
filesCompacting in replaceStoreFiles, but in the new implementation, since we
do not want to hold the write lock while modifying SFT, we move the lock inside
StoreEngine, so now, we will not hold writeLock while updating filesCompacting,
which introduce the problem.
Let me think how to fix this.
> TestWriteHeavyIncrementObserver is flaky
> ----------------------------------------
>
> Key: HBASE-26674
> URL: https://issues.apache.org/jira/browse/HBASE-26674
> Project: HBase
> Issue Type: Bug
> Reporter: Duo Zhang
> Priority: Major
>
> The stacktrace
> {noformat}
> java.lang.IllegalArgumentException
> at
> org.apache.hbase.thirdparty.com.google.common.base.Preconditions.checkArgument(Preconditions.java:131)
> at
> org.apache.hadoop.hbase.regionserver.compactions.SortedCompactionPolicy.getCurrentEligibleFiles(SortedCompactionPolicy.java:173)
> at
> org.apache.hadoop.hbase.regionserver.compactions.SortedCompactionPolicy.preSelectCompactionForCoprocessor(SortedCompactionPolicy.java:44)
> at
> org.apache.hadoop.hbase.regionserver.DefaultStoreEngine$DefaultCompactionContext.preSelect(DefaultStoreEngine.java:130)
> at
> org.apache.hadoop.hbase.regionserver.HStore.requestCompaction(HStore.java:1438)
> at
> org.apache.hadoop.hbase.regionserver.HStore.requestCompaction(HStore.java:1419)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.compact(HRegion.java:2238)
> at
> org.apache.hadoop.hbase.coprocessor.example.TestWriteHeavyIncrementObserver.test(TestWriteHeavyIncrementObserver.java:70)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at
> org.apache.hadoop.hbase.SystemExitRule$1.evaluate(SystemExitRule.java:38)
> at
> org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:299)
> at
> org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:293)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Haven't seen it flaky before. And this is a runtime exception in our non test
> code base, which seems critical.
> Not sure if it has the same root cause with HBASE-26644.
> Need to dig more.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
