Uh oh!
There was an error while loading. Please reload this page.
HBASE-26938 Compaction failures after StoreFileTracker integration (branch-2, branch-2.5) - #4334
HBASE-26938 Compaction failures after StoreFileTracker integration (branch-2, branch-2.5)#4334apurtell wants to merge 1 commit into
Conversation
ab7ff35 to
79617adCompareApache-HBase
commented
Apr 9, 2022
🎊 +1 overall
This message was automatically generated. |
Apache-HBase
commented
Apr 9, 2022
🎊 +1 overall
This message was automatically generated. |
Apache-HBase
commented
Apr 9, 2022
🎊 +1 overall
This message was automatically generated. |
Apache-HBase
commented
Apr 10, 2022
🎊 +1 overall
This message was automatically generated. |
Apache-HBase
commented
Apr 10, 2022
🎊 +1 overall
This message was automatically generated. |
Apache-HBase
commented
Apr 10, 2022
🎊 +1 overall
This message was automatically generated. |
…ranch-2, branch-2.5) - Throw an IllegalStateException for the "Writer exists when it should not" case in Compactor. - If a store is already compacting, do not select it for any additional concurrent compaction.
79617ad to
08f8a6dCompareApache-HBase
commented
Apr 11, 2022
🎊 +1 overall
This message was automatically generated. |
Apache-HBase
commented
Apr 11, 2022
💔 -1 overall
This message was automatically generated. |
apurtell
commented
Apr 11, 2022
In the last precommit result |
Apache-HBase
commented
Apr 11, 2022
🎊 +1 overall
This message was automatically generated. |
apurtell
commented
Apr 12, 2022
As mentioned on HBASE-26938, @Apache9 suggested an alternative approach that I accept and will update this PR soon. |
apurtell
commented
Apr 12, 2022
Opened a PR for master, see #4338 . Closing this one. Will pick back the master commit after merge. |
One
Compactorinstance is reused for the lifetime of a store, and it has awriterfield that at issue here.More than one compaction cannot be concurrently selected and executed against a given store or else readers or writers of the
writerfield will encounter multithreaded correctness problems. Yet I am seeing concurrent selection and execution of compaction activity against the store in the test scenario.In the test scenario I have increased the size of the small and large compaction thread pools, to 10 and 5 threads, respectively, and increased the default point for blocking files to 24, and in the scenario the store is flushing furiously. Operation under these conditions used to be reliable, but perhaps only by an accidental serialization of compaction activity prior to the SFT changes.
With this change in place the reliability and performance under the test scenario returns to previous baseline for DEFAULT SFT. No ERRORs.
Suggestions of alternative approaches to fixing this are welcome too.