av9ash/GitBugs huggingface dataset:
Bug: Correct the line logged with flag hbase.procedure.upgrade-to-2-2 in docs
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 24/Feb/23 05:23

The https://hbase.apache.org/book.html#upgrade2.2 doc says to search for a "READY TO ROLLING UPGRADE" log in master after setting the flag whereas no such log exists. The actual log line indicating that procedure store is empty is "UPGRADE OK: All existed procedures have been finished, quit..."
Bug: [hbase-operator-tools] TestMissingTableDescriptorGenerator fails with HBase 2.5.3
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 24/Mar/23 15:29

hbase-operator-tools fails to compile against hbase 2.5.3 with following test failures.
{code:java}
[INFO] Running org.apache.hbase.TestMissingTableDescriptorGenerator
[ERROR] Tests run: 3, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 30.149 s <<< FAILURE! - in org.apache.hbase.TestMissingTableDescriptorGenerator
[ERROR] testTableinfoGeneratedWhenNoTableSpecified(org.apache.hbase.TestMissingTableDescriptorGenerator)  Time elapsed: 16.734 s  <<< ERROR!
java.lang.IllegalArgumentException: hdfs://localhost:51882/user/nihaljain/test-data/de8af727-6c02-7a95-9beb-027d18fc6603/data/default/test-1/.tabledesc/.tableinfo.0000000001.639
	at org.apache.hbase.TestMissingTableDescriptorGenerator.testTableinfoGeneratedWhenNoTableSpecified(TestMissingTableDescriptorGenerator.java:145)

[ERROR] shouldGenerateTableInfoBasedOnFileSystem(org.apache.hbase.TestMissingTableDescriptorGenerator)  Time elapsed: 6.794 s  <<< ERROR!
java.lang.IllegalArgumentException: hdfs://localhost:51961/user/nihaljain/test-data/5ade0aa1-cb9a-a1da-b700-fe808eeda3b9/data/default/test-1/.tabledesc/.tableinfo.0000000001.666
	at org.apache.hbase.TestMissingTableDescriptorGenerator.shouldGenerateTableInfoBasedOnFileSystem(TestMissingTableDescriptorGenerator.java:120)

[ERROR] shouldGenerateTableInfoBasedOnCachedTableDescriptor(org.apache.hbase.TestMissingTableDescriptorGenerator)  Time elapsed: 6.621 s  <<< ERROR!
java.lang.IllegalArgumentException: hdfs://localhost:52022/user/nihaljain/test-data/d858258b-6ba1-8e4f-c118-4e30d8a5136f/data/default/test-1/.tabledesc/.tableinfo.0000000001.666
	at org.apache.hbase.TestMissingTableDescriptorGenerator.shouldGenerateTableInfoBasedOnCachedTableDescriptor(TestMissingTableDescriptorGenerator.java:107)
{code}
Steps to reproduce, run following against hbase-operator-tools master:
{code:java}
mvn clean install -Dhbase.version=2.5.3 -Dhbase-thirdparty.version=4.1.4 {code}
The goal is to allow hbase-operator-tools to compile with hbase 2.5.3 without any failures
Bug: Update compression dependencies
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 23/Mar/23 01:34

Update compression codec dependencies:

- aircompressor 0.21 -> 0.24
- brotli4j 1.8.0 -> 1.11.0
- snappy 1.1.8.4 -> 1.1.9.1
- zstd-jni 1.5.0-4 -> 1.5.4-2

and add a new supplemental model for new brotli4j dependency.
Bug: Change Iterable to List in SnapshotFileCache
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 25/Jan/23 08:57

The HFileCleaners can have low performance on large /archive area when used with slow storage like S3. The snapshot write lock in SnapshotFileCache is held while the file metadata is fetched from S3. Due to this even with multiple cleaner threads only a single cleaner can effectively delete files from the archive.

File metadata collection is performed before SnapshotHFileCleaner just by changing the passed parameter type in FileCleanerDelegate from Iterable to List.

Running with the below cleaner configurations I observed that the lock held in SnapshotFileCache went down from 45000ms to 100ms  when it was running for 1000 files in a directory. The complete evaluation and deletion for this folder took the same time but since the file metadata fetch from S3 was done outside of the lock the multiple cleaner threads were able to run concurrently.
{noformat}
hbase.cleaner.directory.sorting=false
hbase.cleaner.scan.dir.concurrent.size=0.75
hbase.regionserver.hfilecleaner.small.thread.count=16
hbase.regionserver.hfilecleaner.large.thread.count=8
{noformat}

The files to evaluate are already passed in a List to CleanerChore.checkAndDeleteFiles but it is converted to an Iterable to run the checks on the configured cleaners.
Bug: ruby shell not handled SyntaxError exceptions properly
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 17/Mar/23 03:34
Affects Version/s: 2.5.2

hbase:002:0> create 't2', 'cf'
2023-03-14 04:54:50,061 INFO  [main] client.HBaseAdmin: Operation: CREATE, Table Name: default:t2, procId: 2140 completed
Created table t2
Took 1.1503 seconds
=> Hbase::Table - t2
hbase:003:0> alter 't2', NAME ⇒ 'cf', VERSIONS ⇒ 5
SyntaxError: (hbase):3: syntax error, unexpected tIDENTIFIER
alter 't2', NAME ⇒ 'cf', VERSIONS ⇒ 5
                 ^~~
                      eval at org/jruby/RubyKernel.java:1091
                  evaluate at uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/irb/workspace.rb:85
                  evaluate at uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/irb/context.rb:385
                eval_input at uri:classloader:/irb/hirb.rb:115
             signal_status at uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/irb.rb:647
                eval_input at uri:classloader:/irb/hirb.rb:112
  each_top_level_statement at uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/irb/ruby-lex.rb:246
                      loop at org/jruby/RubyKernel.java:1507
  each_top_level_statement at uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/irb/ruby-lex.rb:232
                     catch at org/jruby/RubyKernel.java:1237
  each_top_level_statement at uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/irb/ruby-lex.rb:231
                eval_input at uri:classloader:/irb/hirb.rb:111
                       run at uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/irb.rb:428
                     catch at org/jruby/RubyKernel.java:1237
                       run at uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/irb.rb:427
<main> at classpath:/jar-bootstrap.rb:226
Bug: Client should not be able to restore/clone a snapshot after it's TTL has expired
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 27/Feb/23 10:41
Affects Version/s: 2.5.2

Steps:

precondition : base.master.cleaner.snapshot.interval to 5 min in hbase-site.xml

1. create a table t1 , put some data

2. create a snapshot 'snapt1' with TTL 1 mins

let the TTL expries 

3. disable and drop table t1

4. restore snapshot t1

Actual : restore snapshot successful 

Expected : restore operation should fail and throw specified snapshot TTL expried cant restore

Note : its can consider as improvement point
Bug: hbase-daemon.sh foreground_start should propagate SIGHUP and SIGTERM
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 17/Feb/23 10:14
Affects Version/s: 2.4.17

Running HBase in a container environment, launched using {{{}bin/hbase-daemon.sh foreground_start ...{}}}. Signaling the container for config refresh or for graceful termination doesn't make it through to the JVM process. Rather, the {{trap}} function is unconditionally sending {{{}kill -9{}}}.
Bug: Remove Java reflection used in FSUtils.create() 
Status: Open | Priority: Minor | Resolution: 
Created: 20/Mar/23 20:10

FSUtils.create() uses reflection to access a HDFS API DistributedFileSystem.create() that supports favored node.

This API is added in Hadoop 2.1.0-beta (HDFS-2576) so we can use it directly without reflection.
Bug: The regionStateNode only need remove once in regionOffline
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 14/Mar/23 15:14
Affects Version/s: 2.4.14

The regionStateNode only need remove once in regionOffline when delete a table.

In

org.apache.hadoop.hbase.master.assignment.AssignmentManager#deleteTable

 

why need delete twice? i think one is enougth
Bug: Remove DNS reflection helper method
Status: Open | Priority: Minor | Resolution: 
Created: 20/Mar/23 19:19

HBASE-14594 used a reflection helper method to use an Hadoop API added in 2.8.0. We should remove this reflection from the master branch now.

https://github.com/apache/hbase/blob/fbe3b90e0c4eef1dc13fb2a5ed9381106ca671dd/hbase-common/src/main/java/org/apache/hadoop/hbase/util/DNS.java#L57
Bug: Fix surefire corrupted channel
Status: Open | Priority: Minor | Resolution: 
Created: 15/Mar/23 09:15

Testing, at least with hbase-server, emits a warning,

{noformat}
[WARNING] Corrupted channel by directly writing to native stream in forked JVM 1. See FAQ web page and the dump file /home/jenkins/jenkins-home/workspace/Base-PreCommit-GitHub-PR_PR-5036/yetus-jdk8-hadoop2-check/src/hbase-server/target/surefire-reports/2023-03-14T13-20-30_932-jvmRun1.dumpstream
{noformat}

I cannot tell if this is causing maven to recognize the test run as a failure, though in this case, the test run was marked as failing, with two tests rerun and passing on their second attempt.

Surefire apparently uses stdio to communicate with maven, so when our code under test produces output on the channel, it corrupts that communication.

https://maven.apache.org/surefire/maven-surefire-plugin/examples/process-communication.html#the-tcp-ip-communication-channel
Bug: ZStdCodec codec implementation class documentation typo
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 10/Mar/23 15:03

As mentioned in the [user@hbase.apache.org|mailto:user@hbase.apache.org] mailing list I noticed a small typo in the documentation on compression for Zstd. The codec implementation class in the documentation is listed as {{org.apache.hadoop.hbase.io.compress.zstd.ZStdCodec}} while the actual class is written with a lower case S: {{ZStdCodec.}}
Bug: rolling-restart.sh stop all masters at the same time
Status: Open | Priority: Minor | Resolution: 
Created: 10/Mar/23 06:35

The rolling-restart.sh in $HBASE_HOME/bin would stop all master service (including the backup ones) at the same time, and then restart them at the same time:
{code:java}
# The content of rolling-restart.sh
...
# stop all masters before re-start to avoid races for master znode
"$bin"/hbase-daemon.sh --config "${HBASE_CONF_DIR}" stop master
"$bin"/hbase-daemons.sh --config "${HBASE_CONF_DIR}" \
--hosts "${HBASE_BACKUP_MASTERS}" stop master-backup

# make sure the master znode has been deleted before continuing
zmaster=`$bin/hbase org.apache.hadoop.hbase.util.HBaseConfTool
zookeeper.znode.master`
...

# all masters are down, now restart
"$bin"/hbase-daemon.sh --config "${HBASE_CONF_DIR}"
${START_CMD_DIST_MODE} master
"$bin"/hbase-daemons.sh --config "${HBASE_CONF_DIR}" \
--hosts "${HBASE_BACKUP_MASTERS}" ${START_CMD_DIST_MODE} master-backup {code}
In this way the HMaster service would be unavailable during this period. We can restart them in a more graceful way, like this:
 * Stop the backup masters, and then restart them one by one
 * Stop the active master, then one of the backup master would become active
 * Start the original active master, now it's the backup one

Will upload patch soon.
Bug: Metrics for RPC handlers should provide more info, e.g. avg,max
Status: Open | Priority: Minor | Resolution: 
Created: 02/Mar/23 08:08
Affects Version/s: 2.5.3

We need the distribution info of the handler count to address problems of performance, e.g. the maximum value, the average value of the handlers. 

It is extremly importance for system of low latency requests.
Bug: Verify replication reporting excessive BADROWS
Status: Open | Priority: Minor | Resolution: 
Created: 14/Feb/23 22:47

Verify replication can generate a lot of `BADROWS` results when comparing a row that may be particularly hot at the time of re-compare. This can lead to a mismatch between the source and sink result due to replication lag. 

We could add some configurable re-compare mechanism that will make verify replication less susceptible to falsely reporting `BADROWS` when under significant write load. These re-compares can be done asynchronously so as to not significantly slow down the execution time of the job.
Bug: ThreadGroup is removed since Hadoop 3.2.4
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 27/Jan/23 10:57

Found lots of WARNING in UT log:
{code:java}
2023-01-26T05:26:18,869 WARN  [FsDatasetAsyncDiskServiceFixer] hbase.HBaseTestingUtil$FsDatasetAsyncDiskServiceFixer(617): failed to reset thread pool timeout for FsDatasetAsyncDiskService
java.lang.NoSuchFieldException: threadGroup
	at java.lang.Class.getDeclaredField(Class.java:2411) ~[?:?]
	at org.apache.hadoop.hbase.HBaseTestingUtil$FsDatasetAsyncDiskServiceFixer.run(HBaseTestingUtil.java:609) ~[test-classes/:?]
{code}

FsDatasetAsyncDiskServiceFixer is introduced by [HBASE-27148|https://issues.apache.org/jira/browse/HBASE-27148], to prevent unexpected kill.

But Hadoop 3.2.4 has fixed this issue [HDFS-16586|https://issues.apache.org/jira/browse/HDFS-16586] and for now HBase use 3.2.4 on branch master.

So I think maybe can remove these code.
Bug: "Instantiating StoreFileTracker impl" INFO level logging is too chatty
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 24/Jan/23 22:09

<datetime> INFO  [<threadname>] storefiletracker.StoreFileTrackerFactory: instantiating StoreFileTracker impl  .... 

This should be logged at DEBUG level as it is debug information. It is frequently printed in the logs and because it's the same impl every time (although in theory could be varied in table schema) there is no value for operators, it just consumes logging resources.
Bug: [JDK17] Fix failure TestImmutableScan#testScanCopyConstructor
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 25/Jan/23 10:47

{code:java}
[INFO]
[INFO] Results:
[INFO]
[ERROR] Errors:
[ERROR]   TestImmutableScan.testScanCopyConstructor:113->compareGetters:351 » InaccessibleObject Unable to make field private static final long java.util.Collections$UnmodifiableMap.serialVersionUID accessible: module java.base does not "opens java.util" to unnamed module @18be83e4
[INFO]
[ERROR] Tests run: 249, Failures: 0, Errors: 1, Skipped: 0{code}
Bug: CatalogJanitor consistencyCheck cannot report the hole on last region if next table is disabled in meta
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 09/Jan/23 13:14
Affects Version/s: 2.4.15

When doing metaTableConsistencyCheck with ReportMakingVisitor, it will skip to check disabled table. When table before the disabled table in meta has a hole on last region,  it cannot be added to holes pairs.
Bug: [JDK17] Update shade plugin version
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 06/Jan/23 10:54

maven-shade-plugin:3.2.4 cannot support JDK17, if build HBase with releaseTarget=17 will meet this error:

!image-2023-01-06-18-54-09-703.png!

So need to update it's version.
Bug: Bump future from 0.18.2 to 0.18.3 in /dev-support
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 17/Jan/23 22:16
Affects Version/s: 2.4.15

Bump future from 0.18.2 to 0.18.3 in /dev-support.
Dependabot PR: https://github.com/apache/hbase/pull/4980
Bug: Errorprone cleanup in hbase-backup
Status: In Progress | Priority: Minor | Resolution: 
Created: 20/Jan/23 13:36

I noticed a bunch of javac warnings in backporting the backups feature to branch-2. The same problems exist in master branch. Let's cleanup error prone warnings in both branches once the backport lands.

See [https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-4770/10/artifact/yetus-general-check/output/diff-compile-javac-root.txt] for initial set to fix. Mostly in tests.
Bug: Introduce ChaosMonkey Action to print HDFS Cluster status
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 12/Jan/23 13:02
Affects Version/s: 2.4.16

We have ChaosMonkey actions for perturbing HDFS components, but we lack a means to periodically display status/health. Introduce a "dump" action similar to the one we have for HBase.
Bug: balance_rsgroup NullPointerException
Status: Open | Priority: Minor | Resolution: 
Created: 16/Jan/23 10:57

hbase shell

hbase(main):001:0> balance_rsgroup 'default'

ERROR: java.io.IOException
        at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:469)
        at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:133)
        at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:338)
        at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:318)
Caused by: java.lang.NullPointerException

 

hbase server log

2023-01-16 18:53:51,418 INFO  [RpcServer.default.RWQ.Fifo.read.handler=315,queue=85,port=16000] rsgroup.RSGroupAdminEndpoint: Client=xxxxx balance rsgroup, group=default
2023-01-16 18:53:51,421 ERROR [RpcServer.default.RWQ.Fifo.read.handler=315,queue=85,port=16000] ipc.RpcServer: Unexpected throwable object
java.lang.NullPointerException
Bug: ChaosMonkey sometimes generates invalid boundaries for random item selection
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 10/Jan/23 13:29
Affects Version/s: 2.4.16

While running chaos monkey, I occasionally see `IndexOutOfBoundsException` originating from `PolicyBasedChaosMonkey#selectRandomItems`. Looks like we make some false assumptions about the arguments passes to the function.
Bug: Process all patch-unit-root.txt in report-flakies.py 
Status: Open | Priority: Minor | Resolution: 
Created: 05/Jan/23 16:34

The report-flakies.py which parses the output of the unit tests does not review all the patch-unit-root.txt files. The for loop exists on the first found unit test output file and ignores the rest.

Earlier the build only had a single unit test run but the current setup runs multiple builds based on the JDK or Hadoop version. All of these outputs should be parsed by the script.
Bug: Description error in documentation of hbase.ipc.server.callqueue.read.ratio
Status: Open | Priority: Trivial | Resolution: 
Created: 30/Mar/23 11:40

There is an error in this document:[https://github.com/apache/hbase/blob/master/src/main/asciidoc/_chapters/performance.adoc]

In 4.11 Tuning callQueue Options there is a description below:

_A value of {{.6}} uses 60% of the queues for reading and 40% for reading. Given a value of {{10}} for {{{}hbase.ipc.server.num.callqueue{}}}, 6 queues would be used for reads and 4 for writes_

It shoud be :60% of the queues for reading and 40% for writing, not all reading.
Bug: Remove the empty path annotation from ClusterMetricsResource
Status: Resolved | Priority: Trivial | Resolution: Fixed
Created: 19/Feb/23 10:00
Affects Version/s: 2.5.0

I see the following warning on starting HBase Master services.
{code:java}
2023-02-19 03:35:39,034 WARN  [main] internal.Errors: The following warnings have been detected: WARNING: The (sub)resource method getBaseMetrics in org.apache.hadoop.hbase.master.http.api_v1.cluster_metrics.resource.ClusterMetricsResource contains empty path annotation. {code}
Bug: Spotless fix in RELEASENOTES.md
Status: Resolved | Priority: Trivial | Resolution: Fixed
Created: 09/Feb/23 15:58
Affects Version/s: 2.4.16

There is a whitespace vilotation in RELEASENOTES.md on branch-2.4 and branch-2.5 causing the pre-commit and nightly builds to fail.

{noformat}
[ERROR] Failed to execute goal com.diffplug.spotless:spotless-maven-plugin:2.27.2:check (default-cli) on project hbase: The following files had format violations:
[ERROR]     RELEASENOTES.md
[ERROR]         @@ -85,7 +85,7 @@
[ERROR]          
[ERROR]          *Â·[HBASE-27529](https://issues.apache.org/jira/browse/HBASE-27529)Â·|Â·*Major*Â·|Â·**ProvideÂ·RSÂ·coprocÂ·abilityÂ·toÂ·attachÂ·WALÂ·extendedÂ·attributesÂ·toÂ·mutationsÂ·atÂ·replicationÂ·sink**
[ERROR]          
[ERROR]         -NewÂ·regionserverÂ·coprocÂ·endpointsÂ·thatÂ·canÂ·beÂ·usedÂ·byÂ·coprocÂ·atÂ·theÂ·replicationÂ·sinkÂ·clusterÂ·ifÂ·WALÂ·hasÂ·extendedÂ·attributes.Â·
[ERROR]         +NewÂ·regionserverÂ·coprocÂ·endpointsÂ·thatÂ·canÂ·beÂ·usedÂ·byÂ·coprocÂ·atÂ·theÂ·replicationÂ·sinkÂ·clusterÂ·ifÂ·WALÂ·hasÂ·extendedÂ·attributes.
[ERROR]          UsingÂ·theÂ·newÂ·endpoints,Â·WALÂ·extendedÂ·attributesÂ·canÂ·beÂ·transferredÂ·toÂ·MutationÂ·attributesÂ·atÂ·theÂ·replicationÂ·sinkÂ·cluster.
{noformat}
Bug: The GET call for column keys becomes significantly slower when it follows lexicographically prior deleted cells. [PERFORMANCE BLOAT]
Status: Open | Priority: Critical | Resolution: 
Created: 26/Jun/24 14:38
Affects Version/s: 2.5.5

*Steps to Reproduce :* 

1. Ensure the column family of the table is configured with MIN_VERSION = 1 and KEEP_DELETED_CELLS = true to ensure that deleted cells remain even after deletion (this is to ensure that flush/compaction doesn't remove deleted cells).
2. Add multiple column keys against a single row key. In this case, use a timestamp (SET1).
3. Use a GET call (GET1) with an iterator-based design to get all the keys. Use the ColumnPaginationFilter and RangeKeyFilter to achieve this (refer to the attached HbaseGet.java file for implementation details).
4. Note the time taken for GET1 (e.g., ~1 second for 100,000 entries).
5. Delete all the added column keys (SET1).
6. Add another set of 100,000 entries (SET2).
7. Use the GET call again (GET2) to retrieve the data and note the time taken.

*Expected Behavior:*
The time taken for GET2 should be similar to GET1, approximately ~1 second.

*Actual Behavior:*
The time taken for GET2 increases significantly, approximately 60 seconds, which is ~50 times longer than GET1.

*Additional Information:*
i) If, after the first delete (SET1), data with lexicographically prior characters (e.g., "0") are added before the deleted cells (timestamp), the GET call time remains consistent with GET1, approximately 1200 ms.

ii) If all 200,000 entries are retrieved without deleting the first set (SET1), the total time is around 2 to 3 seconds. However, deleting SET1 causes GET2 to take 50 times longer than GET1.

*Suggested Fix:*
Temporarily, to fix this issue, add a dummy column key with a lexicographically prior character (e.g., "0") to ensure consistent GET call times.

*Note:*
Please refer to the attached [^HbaseGet.java], RegionserverFlameGraph  and dataFlow for detailed steps to reproduce the issue.
Bug: Only allow one TableProcedureInterface for a single table to run at the same time for some special procedure types
Status: Resolved | Priority: Critical | Resolution: Fixed
Created: 20/Jun/24 15:13

We have a table lock in the MasterProcedureScheduler, which is designed to only allow one procedure to run at the same time when they require exclusive lock.

But there is a problem that for availability, usually we can not always hold the exclusive lock through the whole procedure life time, as if so, we can not execute region assignment for this table too. The solution is to set holdLock to false, which means we will release the table lock after one execution cycle.

In this way, it is possible that different table procedures may execute at the same time, which could mess things up.

Especially that, in HBASE-28522, we find out that it is even impossible for DisableTableProcedure to hold the exclusive lock all the time. If the steps for DisableTableProcedure can be overlapped with other procedures like ModifyTableProcedure or even EnableTableProcedure, things will be definationly messed up...

So we need to find another way to ensure that for a single table, only one of these procedures can be executed at the same time.