av9ash/GitBugs huggingface dataset:
Bug: TLS RPC unit tests are failing in precommit builds
Status: Open | Priority: Major | Resolution: 
Created: 16/May/23 21:37

For example:

https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5240/1/artifact/yetus-jdk8-hadoop3-check/output/patch-unit-hbase-server.txt

ERROR] Failures: 
[ERROR]   TestSaslTlsIPC>AbstractTestSecureIPC.testSaslNoCommonQop:284 unexpected exception type thrown; expected:<javax.security.sasl.SaslException> but was:<java.security.cert.CertificateExpiredException>

[ERROR] Errors: 
[ERROR]   TestSaslTlsIPC.testDifferentConfWithCryptoAES[4: caKeyType=RSA, certKeyType=RSA, keyPassword=[C@1f760b47, acceptPlainText=true, clientTlsEnabled=true] Â» CertificateExpired NotAfter: Tue May 16 00:00:00 GMT 2023
[ERROR]   TestSaslTlsIPC.testRpcCallWithEnabledKerberosSaslAuthCanonicalHostname[3: caKeyType=RSA, certKeyType=RSA, keyPassword=[C@1f760b47, acceptPlainText=false, clientTlsEnabled=true] Â» CertificateExpired NotAfter: Tue May 16 00:00:00 GMT 2023
[ERROR]   TestSaslTlsIPC.testRpcCallWithEnabledKerberosSaslAuthCanonicalHostname[4: caKeyType=RSA, certKeyType=RSA, keyPassword=[C@1f760b47, acceptPlainText=true, clientTlsEnabled=true] Â» CertificateExpired NotAfter: Tue May 16 00:00:00 GMT 2023
[ERROR]   TestSaslTlsIPC.testRpcCallWithEnabledKerberosSaslAuthNoCanonicalHostname[3: caKeyType=RSA, certKeyType=RSA, keyPassword=[C@1f760b47, acceptPlainText=false, clientTlsEnabled=true] Â» CertificateExpired NotAfter: Tue May 16 00:00:00 GMT 2023
[ERROR]   TestSaslTlsIPC.testRpcCallWithEnabledKerberosSaslAuthNoCanonicalHostname[4: caKeyType=RSA, certKeyType=RSA, keyPassword=[C@1f760b47, acceptPlainText=true, clientTlsEnabled=true] Â» CertificateExpired NotAfter: Tue May 16 00:00:00 GMT 2023
[ERROR]   TestSaslTlsIPC.testRpcCallWithEnabledKerberosSaslAuth[4: caKeyType=RSA, certKeyType=RSA, keyPassword=[C@1f760b47, acceptPlainText=true, clientTlsEnabled=true] Â» CertificateExpired NotAfter: Tue May 16 00:00:00 GMT 2023
[ERROR]   TestSaslTlsIPC.testRpcFallbackToSimpleAuth[4: caKeyType=RSA, certKeyType=RSA, keyPassword=[C@1f760b47, acceptPlainText=true, clientTlsEnabled=true] Â» CertificateExpired NotAfter: Tue May 16 00:00:00 GMT 2023
[ERROR]   TestSaslTlsIPC.testSaslWithCommonQop[4: caKeyType=RSA, certKeyType=RSA, keyPassword=[C@1f760b47, acceptPlainText=true, clientTlsEnabled=true] Â» CertificateExpired NotAfter: Tue May 16 00:00:00 GMT 2023
[ERROR]   TestSaslTlsIPC.testSaslWithCryptoAES[4: caKeyType=RSA, certKeyType=RSA, keyPassword=[C@1f760b47, acceptPlainText=true, clientTlsEnabled=true] Â» CertificateExpired NotAfter: Tue May 16 00:00:00 GMT 2023

[WARNING] Flakes: 
[WARNING] org.apache.hadoop.hbase.security.TestNettyTLSIPCFileWatcher.testReplaceClientAndServerKeystore[1: keyType=RSA, storeFileType=PEM]
[ERROR]   Run 1: TestNettyTLSIPCFileWatcher.testReplaceClientAndServerKeystore:221 NullPointer
[INFO]   Run 2: PASS
Bug: Use a separate WAL provider for hbase:replication table
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 04/Apr/23 07:19

TestMultiSlaveReplication fails when using table based replication queue storage

The test uses a small wal rolling size for testing more operations

{code}
    // smaller block size and capacity to trigger more operations
    // and test them
    conf1.setInt("hbase.regionserver.hlog.blocksize", 1024 * 20);
    conf1.setInt("replication.source.size.capacity", 1024);
{code}

But after moving to table based replication queue storage, the update to hbase:replication tablr will also be append to the same WAL file, so it will make the replicaton worker move forward, and then it will update the hbase:replication table since the offset has been changed, so then it will make the replication work again, and so on...

This will make the wal file size reach the configured size easily and trigger unexpected wal rolling, and then fail the test.

For fixing the test, we can increase the wal rolling size, or we can use multi wal, to separate the wal files of hbase:replication table along. so it will not mess up the normal wal files.
Bug: TestThriftServerCmdLine fails with org.apache.hadoop.hbase.SystemExitRule$SystemExitInTestException
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 14/May/23 15:37

https://ci-hbase.apache.org/job/HBase%20Nightly/job/master/839/testReport/junit/org.apache.hadoop.hbase.thrift/TestThriftServerCmdLine/health_checks___yetus_jdk11_hadoop3_checks___testRunThriftServer_13_/

{noformat}
org.apache.hadoop.hbase.SystemExitRule$SystemExitInTestException
	at org.apache.hadoop.hbase.TestSecurityManager.checkExit(TestSecurityManager.java:32)
	at java.base/java.lang.Runtime.exit(Runtime.java:114)
	at java.base/java.lang.System.exit(System.java:1752)
	at org.apache.hadoop.hbase.thrift.ThriftServer$2.run(ThriftServer.java:850)
	at java.base/java.security.AccessController.doPrivileged(Native Method)
	at java.base/javax.security.auth.Subject.doAs(Subject.java:361)
	at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1742)
	at org.apache.hadoop.hbase.thrift.ThriftServer.run(ThriftServer.java:836)
	at org.apache.hadoop.hbase.thrift.ThriftServerRunner.run(ThriftServerRunner.java:54)
{noformat}
Bug: HMaster.getCompactionState's return result about table compaction state is not quite right 
Status: Open | Priority: Major | Resolution: 
Created: 12/May/23 13:30
Affects Version/s: 2.3.7

1. The table compaction state should be NONE if all of those regions is online and is not compacting.


2. The Table compaction state should be null if one of those regions is not online and others is not compacting.  null means that the table compaction state we obtained is UNKOWN.

 

3. The Table compaction state should be minor/major when there are regions which is compacting
Bug: Skip family comparing when compare cells inner the store
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 11/Apr/23 09:29

Currently we use CellComparatorImpl to compare cells, it compare row first, then family, then qulifier and so on.

If the comparing inner the store, the families are always equal(unless the familyLength is zero for special purpose), so this step could be skipped for better performance.
Bug: NPE in ClaimReplicationQueuesProcedure when running TestAssignmentManager.testAssignSocketTimeout
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 03/May/23 12:07

{quote}
2023-05-03T05:56:10,094 ERROR [PEWorker-18 {}] procedure2.ProcedureExecutor(1669): CODE-BUG: Uncaught runtime exception: pid=8, ppid=5, state=RUNNABLE, hasLock=true; org.apache.hadoop.hbase.master.replication.ClaimReplicationQueuesProcedure
java.lang.NullPointerException: null
	at org.apache.hadoop.hbase.master.replication.ClaimReplicationQueuesProcedure.execute(ClaimReplicationQueuesProcedure.java:83) ~[classes/:?]
	at org.apache.hadoop.hbase.master.replication.ClaimReplicationQueuesProcedure.execute(ClaimReplicationQueuesProcedure.java:48) ~[classes/:?]
	at org.apache.hadoop.hbase.procedure2.Procedure.doExecute(Procedure.java:919) ~[hbase-procedure-3.0.0-alpha-4-SNAPSHOT.jar:3.0.0-alpha-4-SNAPSHOT]
	at org.apache.hadoop.hbase.procedure2.ProcedureExecutor.execProcedure(ProcedureExecutor.java:1650) ~[hbase-procedure-3.0.0-alpha-4-SNAPSHOT.jar:3.0.0-alpha-4-SNAPSHOT]
	at org.apache.hadoop.hbase.procedure2.ProcedureExecutor.executeProcedure(ProcedureExecutor.java:1396) ~[hbase-procedure-3.0.0-alpha-4-SNAPSHOT.jar:3.0.0-alpha-4-SNAPSHOT]
	at org.apache.hadoop.hbase.procedure2.ProcedureExecutor.access$1000(ProcedureExecutor.java:75) ~[hbase-procedure-3.0.0-alpha-4-SNAPSHOT.jar:3.0.0-alpha-4-SNAPSHOT]
	at org.apache.hadoop.hbase.procedure2.ProcedureExecutor$WorkerThread.runProcedure(ProcedureExecutor.java:1962) ~[hbase-procedure-3.0.0-alpha-4-SNAPSHOT.jar:3.0.0-alpha-4-SNAPSHOT]
	at org.apache.hadoop.hbase.trace.TraceUtil.trace(TraceUtil.java:216) ~[hbase-common-3.0.0-alpha-4-SNAPSHOT.jar:3.0.0-alpha-4-SNAPSHOT]
	at org.apache.hadoop.hbase.procedure2.ProcedureExecutor$WorkerThread.run(ProcedureExecutor.java:1989) ~[hbase-procedure-3.0.0-alpha-4-SNAPSHOT.jar:3.0.0-alpha-4-SNAPSHOT]
{quote}

We mock lots of things in this test so not sure this is a test issue or a real issue.

Need to dig more.

This should be a possible reason that why this test is flaky.
Bug: TestFromClientSide5.testAppendWithoutWAL is flaky
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 28/Apr/23 11:26

Not sure whether it is also flaky on branch-2.x, but at least on master, when we call Table.getScanner and get the returned ResultScanner, it does not mean that we have finished sending the request to region server, as the actual implementation is asynchronous. If we want a stable result, we need to at least get one row from the scanner.
Bug: Store file archiving is not sufficiently indirected through the store file tracker
Status: Open | Priority: Major | Resolution: 
Created: 03/May/23 16:04
Affects Version/s: 2.5.4

GCRegionProcedure fails cleaning up old parents after splits. We time out “renaming” files into the archive. On S3, a rename operation is a whole file copy operation. It can take a long time to copy a large hfile.

{noformat}
[PEWorker-21] backup.HFileArchiver: Failed to archive FileablePath, s3a://[...]
java.net.SocketTimeoutException: copyFile(data/default/cluster_test/[...], 
archive/data/default/cluster_test/[...]) on data/default/cluster_test/[...]: 
com.amazonaws.SdkClientException: Unable to execute HTTP request: Read timed out
{noformat}

Once we fail to “rename” the files into the archive we continue to fail because renames on S3 are not atomic. They are an object copy operation which is neither atomic nor automatically rolled back. The incomplete object remains present. The GCRegionProcedure can never complete successfully.

{noformat}
org.apache.hadoop.fs.FileAlreadyExistsException: Failed to rename s3a://[...] to s3a://[...]; 
destination file exists
{noformat}

{noformat}
org.apache.hadoop.hbase.backup.FailedArchiveException: Failed to archive/delete all the files for region:
ddaf1fb41197254483dcfd1d63e869d0 into s3a://[...]. 
Something is probably awry on the filesystem.
{noformat}

Short term mitigations:

In HFileArchiver#resolveAndArchiveFile, if moveAndClose of the current file fails, attempt to delete the incomplete archive side file.

Also set the recommended default read timeout for S3A to a larger value.

Long term:

When the file based store file tracker is enabled, the archived files for a store should not longer be moved to a separate path from the live files in the store. Instead whether or not the file is archived or not should be a status bit maintained in the tracker manifest.
Bug: WalPlayer does not acquire delegation tokens for namenodes
Status: Resolved | Priority: Major | Resolution: Duplicate
Created: 04/May/23 16:04

The WalPlayer does not acquire delegation tokes for namenodes when creating the job. This results in the WalPlayer being unable to authenticate correctly with the namenodes the WALs live on.

 
{code:java}
No HA service delegation token found for logical URI <uri> {code}
Bug: HBCK throws RejectedExecutionException when closing ZooKeeper resources
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 25/Apr/23 15:49
Affects Version/s: 2.4.17

HBCK throws RejectedExecutionException at the end of run, because the order of closing ZooKeeper resources has been swapped in HBASE-27426.

In ZKWatcher.java close() method first it shuts down the zkEventProcessor and when it fully shut down, it closes the RecoverableZooKeeper (the ZK client). The watcher receives the close event which cannot be submitted to the event processor and throws exception.

I think we need to check whether the executor is able to receive jobs before submitting.
Bug: Change flatten mode for oss in our pom file
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 21/Apr/23 15:16
Affects Version/s: 2.5.5

Per the discussion here: https://lists.apache.org/thread/b971svby2js6qgzcbso71dfh8t4mly6j

We plan to change the flatten mode to oss instead of default, to retain more sections in our pom file.
Bug: Split TestReplicationDroppedTables
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 27/Apr/23 15:18

It is flaky in pre commit for a long time, usually because of time out. But it always pass for me locally, as well as in nightly job(that's also why it does not in the flaky list

It has 4 tests, not sure which one is the criminal, so I think we could split it into 4 standalone tests, so if it still fails, we can find out the actual flaky one.
Bug: Encapsulate and centralize totalBufferUsed in ReplicationSourceManager
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 10/Apr/23 13:40
Affects Version/s: 3.0.0-alpha-3

 {{ReplicationSourceManager.totalBufferUsed}} is a counter, and is scoped to {{ReplicationSourceManager}}, but it is copied to {{ReplicationSource}} and {{ReplicationSourceWALReader}}, which makes the logic about {{ReplicationSourceManager.totalBufferUsed}} is scattered throughout {{ReplicationSourceManager}},{{ReplicationSource}},{{ReplicationSourceWALReader}} and {{ReplicationSourceShipper}}. It causes duplicated code and would make tracing the buffer usage somewhat difficult when there is problem about {{totalBufferUsed}}. I think we should encapsulate and centralize it in {{ReplicationSourceManager}}.
Bug: Implement a shell command to disable all peer modification
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 08/Apr/23 03:09

This is used to switch peer storage implementation online.

We can switch the peer storage like this:

1. Disable all peer modification.
2. Run the migration tool to migrate peer data from one storage to another.
3. Change all the hbase-site.xml files in the cluster.
4. Trigger online configuration change.
5. Enable peer modification.
Bug: Upgrade vega and its related js libraries
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 12/Apr/23 11:19
Affects Version/s: 2.5.0

HBase is using Vega, v5.19.1, which was released on 21 Jan, 2021 and is vulnerable to cross-site scripting (XSS), CVE IDs:
 * [CVE-2023-26486|https://nvd.nist.gov/vuln/detail/CVE-2023-26486]
 * [CVE-2023-26487|https://nvd.nist.gov/vuln/detail/CVE-2023-26487]

This Jira is to upgrade to latest releases:
 * [https://github.com/vega/vega/releases/tag/v5.24.0]
 * [https://github.com/vega/vega-lite/releases/tag/v5.6.1]
 * [https://github.com/vega/vega-embed/releases/tag/v6.21.3]
Bug: Improve MemcachedBlockCache
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 14/Apr/23 17:57
Affects Version/s: 2.5.4

MemcachedBlockCache is apparently not used, given the bugs I have found, but provides some useful functionality that we are investigating at $dayjob. Fix it.

 - Track and log better stats

- Fix use of memcached API such that we are not accidentally immediately expiring keys.

- Use a default retention period of 30 days, the max per memcached spec

- Use set instead of add to store keys

- Gracefully handle failures to cache and read timeouts

- Add unit tests using jmemcached as a test dependency
Bug: Manage static javascript resources programatically
Status: Open | Priority: Major | Resolution: 
Created: 18/Apr/23 15:23

Currently, the static JavaScript resources need to be manually managed. That is, if any of these has to be updated, we will be required to download them from web and place them under the appropriate path. This can be cumbersome.

See list of JS under hbase-server at [https://github.com/apache/hbase/tree/master/hbase-server/src/main/resources/hbase-webapps/static/js]

Need to find a way to manage them with minimal manual effort. Best case would be to manage them as part of build.
Bug: Data is deleted after the compaction and MOB cleaning operation
Status: Open | Priority: Major | Resolution: 
Created: 12/Apr/23 08:27
Affects Version/s: 2.5.3

I'm trying to save image binaries in the MOB column.
 
The column option is as follows:
{INDEX_BLOCK_ENCODING => 'NONE', MOB_THRESHOLD => '102400', VERSIONS => '1', KEEP_DELETED_CELLS => 'FALSE', DATA_BLOCK_ENCODING => 'NONE', TTL => 'FOREVER', MIN_VERSIONS => '0', REPLICATION_SCOPE => '0', BLOOMFILTER => 'ROW', IN_MEMORY => 'false', IS_MOB => 'true', COMPRESSION => 'NONE', BLOCKCACHE => 'true', BLOCKSIZE => '65536 B (64KB)}
 
I set the `hbase.master.mob.cleaner.period` as 3600 (1h) and called `major_compact` in the shell, 
to test if the compaction works as I expected.
As a result, StorefileSize became 0 MB without any other operations being done on the table.
Is it possible that the compaction job deletes all the data from the column?
 
The lost data size was about 150 TB and I am using 2000 region servers. (Data from other columns is fine)
File count from the MOB directory decreased from 525K to 78K after the compaction + mob cleaning.
 
I could not find anything about deleting data from the hbase logs, and it is unlikely that any other process deleted the data. (I wrote the data to the newly build hbase cluster)
 
I wonder if there can be a reason why all the data is gone.
Bug: FileChangeWatcher improvements
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 05/Apr/23 13:48

HBASE-27347 ported FileChangeWatcher from ZK so that we can reload certificates when the keystore/truststore files change. I'd like to make a few improvements:
 # Add more context to the thread name, so that we can disambiguate when multiple are launched for different cluster connections or paths
 # We currently launch a separate FileChangeWatcher for each of keystorePath and truststorePath, but in many cases they may be the same path. The runnable which gets called is identical for these, so this just results in extra work for no reason. We should check the configured paths and only launch one FileChangeWatcher if the two paths are identical.
Bug: CompoundBloomFilters break with an error rate that is too high
Status: Open | Priority: Major | Resolution: 
Created: 10/Apr/23 19:27
Affects Version/s: 2.5.2

At my company we're beginning to more heavily utilize the bloom error rate configuration. This is because bloom filters are a nice optimization, but for well distributed workloads with relatively dense data (many rows:host), we've found that they can cause lots of memory/GC pressure unless they can entirely fit in the block cache (and consequently not churn memory that's subject to GC).

Because it's easier to estimate the memory requirements of changes in existing bloom filters, rather than net new bloom filters, we wanted to begin with very high bloom error rates (and consequently small bloom filters), and then ratchet down as memory availability allowed.

This led to us discovering that bloom filters appear to become corrupt at a relatively arbitrary error rate threshold. Blooms with an error rate of 0.61 work as expected, but produce nonsensical results with an error rate of 0.62. I've pushed this branch with test updates to demonstrate the deficit: [https://github.com/apache/hbase/compare/master...HubSpot:hbase:rmattingly/bloom-error-rate-bug]

The test changes confirm that the BloomFilterUtil works as expected, at least with respect to its error rate : size relationship. You can see this in the output of {{{}TestBloomFilterChunk#testBloomErrorRateSizeRelationship{}}}:

 
{noformat}
previousErrorRate=0.01, previousSize=1048568
currentErrorRate=0.05, currentSize=682109
previousErrorRate=0.05, previousSize=682109
currentErrorRate=0.1, currentSize=524284
previousErrorRate=0.1, previousSize=524284
currentErrorRate=0.2, currentSize=366459
previousErrorRate=0.2, previousSize=366459
currentErrorRate=0.4, currentSize=208634
previousErrorRate=0.4, previousSize=208634
currentErrorRate=0.5, currentSize=157826
previousErrorRate=0.5, previousSize=157826
currentErrorRate=0.75, currentSize=65504
previousErrorRate=0.75, previousSize=65504
currentErrorRate=0.99, currentSize=2289
{noformat}
 

With this in mind, the updates to {{TestCompoundBloomFilter}} tell us that the bug must live somewhere in the {{CompoundBloomFilter}} logic. The output indicates this:

 
{noformat}
2023-04-10T15:07:50,925 INFO  [Time-limited test] regionserver.TestCompoundBloomFilter(245): Functional bloom has error rate 0.01 and size 1kb
...
2023-04-10T15:07:56,657 INFO  [Time-limited test] regionserver.TestCompoundBloomFilter(245): Functional bloom has error rate 0.61 and size 1kb
...
java.lang.AssertionError: False positive is too high: 0.9998533333333334 (greater than 0.65), fake lookup is enabled. Bloom size is 4687kb
    at org.junit.Assert.fail(Assert.java:89)
    at org.junit.Assert.assertTrue(Assert.java:42)
    at org.apache.hadoop.hbase.regionserver.TestCompoundBloomFilter.readStoreFile(TestCompoundBloomFilter.java:243)
{noformat}
 

The bloom size change from ~1kb -> 4687kb and total lack of precision is clearly not as intended, and totally inline with what we saw in our HBase clusters that attempted to use high bloom error rates.
Bug: Incorrect  ReplicationSourceWALReader. totalBufferUsed may cause replication hang up
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 04/Apr/23 13:42
Affects Version/s: 2.4.17

When we read a new WAL Entry in {{ReplicationSourceWALReader.readWALEntries}}, we add {{ReplicationSourceWALReader.totalBufferUsed}} by the size of new entry in   {{ReplicationSourceWALReader.addEntryToBatch}}, but the whole {{WALEntryBatch}} may not be put to the {{ReplicationSourceWALReader.entryBatchQueue}} because of exception(eg. exception thrown by {{WALEntryFilter.filter}} for following WAL Entry), and the {{ReplicationSourceWALReader.totalBufferUsed}} is not decreased in this case. Because the  {{ReplicationSourceWALReader.totalBufferUsed}}  is actually scoped to {{ReplicationSourceManager}}, after a long run, replication to all peers may hang up.
Bug: Complete Release 2.4.17
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 01/Apr/23 01:01

# Release the artifacts on repository.apache.org
 # Move the binaries from dist-dev to dist-release
 # Add xml to download page
 # Push tag 2.4.17RC0 as tag rel/2.4.17
 # Release 2.4.17 on JIRA https://issues.apache.org/jira/projects/HBASE/versions/12352760
 # Add release data on [https://reporter.apache.org/addrelease.html?hbase]
 # Send announcement email
Bug: bin/hbase --help does not list "omnibus_tarball" options
Status: Open | Priority: Major | Resolution: 
Created: 04/Apr/23 12:26
Affects Version/s: 2.4.17

Launching {{bin/hbase --help}} from the 2.4.17RC0 full distribution tarball, I see a limited set of options. It looks like we do not source hbase-config.sh before printing the help message, which means {{HBASE_HOME}} is not set, and we don't get the extended output.
Bug: Add support for dump and process metrics servlet in REST InfoServer
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 26/Apr/23 10:10

Unlike other HBase Master/RS Info Servers, HBase REST Server does not provide a way to:
 * Get debug dump for quick access to stacks, logs etc.
 * Get process metrics like threads, gc collectors etc.

This task is add the above in HBase REST InfoServer.
Bug: Skip submitting Split/Merge procedure when split/merge is disabled at table level
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 02/Jun/23 11:26

*Scenario*

If split/merge is disabled at table level , master will submit a SplitTableRegionProcedure/MergeTableRegionsProcedure , and rollback it as execution fails during pre-checks .

*Improvement*

Master can check it early and no need to submit SplitTableRegionProcedure/MergeTableRegionsProcedure when split/merge switch is disabled at Table level.

*Steps*
{code:java}
create 'testCreateTableWithMergeDisableParameter', 'f1', {MERGE_ENABLED => false}
list_regions 'testCreateTableWithMergeDisableParameter'
merge_region 'd21cdc5d488e8036017696c46cffd9b1','6382c8f731a4f0379b6e98ece4b06e3e'
{code}
{code:java}
create 'testcreatetablewithsplitdisableparameter', 'f1', {SPLIT_ENABLED => false}
split 'testcreatetablewithsplitdisableparameter','30'{code}