av9ash/GitBugs huggingface dataset:
Bug: Server+table counters on each scan #nextRaw invocation becomes a bottleneck when heavy load
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 18/Mar/21 05:36
Affects Version/s: 2.3.2

On a heavily loaded server mostly doing reads/scan, I saw that 90+% of handlers were BLOCKED in this fashion in thread dumps:

{code}
"RpcServer.default.FPBQ.Fifo.handler=117,queue=17,port=16020" #161 daemon prio=5 os_prio=0 tid=0x00007f748757f000 nid=0x73e9 waiting for monitor entry [0x00007f74783e0000]
  java.lang.Thread.State: BLOCKED (on object monitor)
       at java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1674)
       - waiting to lock <0x00007f7647e3cc38> (a java.util.concurrent.ConcurrentHashMap$Node)
       at org.apache.hadoop.hbase.regionserver.MetricsTableQueryMeterImpl.getOrCreateTableMeter(MetricsTableQueryMeterImpl.java:80)
       at org.apache.hadoop.hbase.regionserver.MetricsTableQueryMeterImpl.updateTableReadQueryMeter(MetricsTableQueryMeterImpl.java:90)
       at org.apache.hadoop.hbase.regionserver.RegionServerTableMetrics.updateTableReadQueryMeter(RegionServerTableMetrics.java:89)
       at org.apache.hadoop.hbase.regionserver.MetricsRegionServer.updateReadQueryMeter(MetricsRegionServer.java:274)
       at org.apache.hadoop.hbase.regionserver.HRegion$RegionScannerImpl.nextRaw(HRegion.java:6742)
       at org.apache.hadoop.hbase.regionserver.RSRpcServices.scan(RSRpcServices.java:3319)
       - locked <0x00007f896c0165a0> (a org.apache.hadoop.hbase.regionserver.HRegion$RegionScannerImpl)
       at org.apache.hadoop.hbase.regionserver.RSRpcServices.scan(RSRpcServices.java:3566)
       at org.apache.hadoop.hbase.shaded.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:44858)
       at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:393)
       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)

{code}

It kept up for good periods of time.

I saw it to a leser extent on other servers, with less load.

These RS had 400+ Regions a good few of which were serving out scan reads; the server was doing ~1M hits a second. In this scenario, I saw the above bottleneck.

Looking at it, it came in w/ when the parent issue feature was added. There are these read counts and then there were also write counts. The write counts are mostly batch-based. Let me do same thing here for the read.... update the central server+table count after scan is done rather than per invocation of #nextRaw.
Bug: Region Servers should give some indication that short-circuit reads are configured properly and working
Status: Open | Priority: Major | Resolution: 
Created: 21/Jan/21 19:56
Affects Version/s: 2.3.0

Going through the exercise of confirming short-circuit reads turns out to be quite a chore. 2.3.0 added a new metric, but metrics only get tickled when there's traffic that happens to use the feature. This is not very convenient for an operator who has taken a cluster out of service for maintenance.

It would be nice if the rs process could perform some test and emitted some confirmation of the status of this otherwise transparent feature. After confirmation, it could light up a boolean metric value and/or add mention of it to the info page.
Bug: Honor TableDescriptor settings earlier in normalization
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 27/Jan/21 08:39
Affects Version/s: 2.4.2

-Table can be enabled and disabled merge/split in TableDescriptor, we should judge before calculating the plan.-

The normalizer configuration can be set by table level. For example, hbase.normalizer.min.region.count can be set by "alter ‘table’, CONFIGURATION=>\{'hbase.normalizer.min.region.count' => '5'}". If the table is not set, then use the global configuration which is set in hbase-site.xml.
Bug: When the table is turned on normalize, the first region may not be merged even the size is 0
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 15/Jan/21 10:01
Affects Version/s: 2.4.1

Suppose a table has 8 regions, the sizes are [0, 10, 1, 0, 9, 0, 12, 0], the average region size is 4, and split is disabled.

The current Normalizer can only get three merge plans (use size to represent region):

[1, 0], [9, 0],[12, 0]

It can not merge the first region, even it's size is 0.
Bug: RegionServer aborted due to ClassCastException
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 30/Mar/21 09:14
Affects Version/s: 2.2.6

{color:#000000}Observed RegionServer crash while writing huge data concurrently through YCSB tool,

{noformat}
2021-03-29 14:35:37,860 | ERROR | RpcServer.priority.RWQ.Fifo.write.handler=19,queue=3,port=RS_PORT | ***** ABORTING region server RS_IP,RS_PORT,1616999325078: The coprocessor org.apache.hadoop.hbase.coprocessor.MetaTableMetrics threw java.lang.ClassCastException: java.util.HashMap$Node cannot be cast to java.util.HashMap$TreeNode ***** | org.slf4j.helpers.MarkerIgnoringBase.error(MarkerIgnoringBase.java:159)
java.lang.ClassCastException: java.util.HashMap$Node cannot be cast to java.util.HashMap$TreeNode
at java.util.HashMap$TreeNode.moveRootToFront(HashMap.java:1835)
at java.util.HashMap$TreeNode.treeify(HashMap.java:1951)
at java.util.HashMap.treeifyBin(HashMap.java:772)
at java.util.HashMap.putVal(HashMap.java:644)
at java.util.HashMap.put(HashMap.java:612)
at java.util.HashSet.add(HashSet.java:220)
at org.apache.hadoop.hbase.coprocessor.MetaTableMetrics$ExampleRegionObserverMeta.registerAndMarkMeter(MetaTableMetrics.java:200)
at org.apache.hadoop.hbase.coprocessor.MetaTableMetrics$ExampleRegionObserverMeta.regionMetricRegisterAndMark(MetaTableMetrics.java:173)
at org.apache.hadoop.hbase.coprocessor.MetaTableMetrics$ExampleRegionObserverMeta.registerAndMarkMetrics(MetaTableMetrics.java:106)
at org.apache.hadoop.hbase.coprocessor.MetaTableMetrics$ExampleRegionObserverMeta.prePut(MetaTableMetrics.java:91)
at org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost$23.call(RegionCoprocessorHost.java:948)
at org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost$23.call(RegionCoprocessorHost.java:945)
at org.apache.hadoop.hbase.coprocessor.CoprocessorHost$ObserverOperationWithoutResult.callObserver(CoprocessorHost.java:581)
at org.apache.hadoop.hbase.coprocessor.CoprocessorHost.execOperation(CoprocessorHost.java:655)
at org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.prePut(RegionCoprocessorHost.java:945)
{noformat}

This problem occured only once in my test cluster. Discussed offline with [~pankajkumar] it looks like race condition in MetaTableMetrics.metrics.{color}
Bug: Reimplement TestCurrentHourProvider to not depend on unstable TZs
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 04/Mar/21 02:14

Because TestCurrentHourProvider is not timezone independent we are subject to vagaries of timezones around the world and the management of TZ data of each test server and dev box. This is not something we want to take on, IMHO. Reimplement to be independent of TZ or remove.
Bug: Optionally allow snapshots to preserve cluster's max filesize config by setting it into table descriptor  
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 03/Feb/21 17:00
Affects Version/s: 2.3.4

While using snapshots for data migration, if the source cluster has non-default definition for *hbase.hregion.max.filesize*, table being snapshotted doesn't have *MAX_FILESIZE* attribute set, then if snapshot is exported to a separate cluster with different value for *hbase.hregion.max.filesize*, any cloned table will not respect the original value. In cases where the original cluster had a much larger value set to *hbase.hregion.max.filesize* then the destination cluster, restoring snapshot can trigger a storm of splits.

This Jira introduces an optional configuration (disabled by default) that allows for the *hbase.hregion.max.filesize* value to be saved within the table *MAX_FILESIZE* descriptor at snapshot creation time.
Bug: Backport to branch-2.2: [HBASE-25548  Optionally allow snapshots to preserve cluster's max filesize config by setting it into table descriptor]
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 10/Mar/21 11:18
Affects Version/s: 2.2.6

Cherry pick of HBASE-25548 had some conflicts, so a new PR to branch-2.2 is needed.
Bug: Balancer should check region plan source to avoid misplace region groups
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 01/Mar/21 11:31

Currently, balancer generates all group plans firstly, and then execute overall plans. When there are table regions movement between groups but after the groups plans generating and before executing, balancer may misplace the region to the old group. But this is not serious problem, next balancer will fix it. 

If we add a check before executing balance plans, we can avoid the problem.
Bug: TestLruBlockCache.testBackgroundEvictionThread is flaky
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 22/Feb/21 12:29

As the test result in [https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2700/2/testReport/org.apache.hadoop.hbase.io.hfile/TestLruBlockCache/precommit_checks___yetus_jdk11_hadoop3_checks___testBackgroundEvictionThread/]

It fails because background EvictionThread used the weak reference of LRUBlockCache, when the cache object is cleared by garbage collector, NO block eviction will be triggered by LruBlockCache#runEviction(). 

.
Bug: [hbck2] Schedule SCP for all unknown servers
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 18/Feb/21 15:42

Add a command to HBCK2 that schedules SCPs for _unknown servers_. This command is useful when a new installation of HBase is pointing to a previously used HBase root directory where the hbase:meta table is populated. This will contain references to RegionServers from the previous installation and SCP will not be created against these servers and the regions won't be assigned to the new server.

The scheduleRecoveries command in HBCK2 could be used to initiate a SCP one-by-one for the unknown servers, however, collecting the list of servers could be difficult on a large cluster.

I'm proposing to add a command to HBCK2 that will schedule SCPs for all the unknown servers in the cluster.
Bug: Add units and round off region size to 2 digits after decimal
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 09/Mar/21 23:03
Affects Version/s: 2.3.0

Normalizer logs progress and includes details regarding region count and target size. The size values are logged without units, and floating point numbers are logged without a specified precision, which can result in scientific notation. Clean up the formatting of these log messages to make them easily readable.
Bug: Support specifying a base split policy class in KeyPrefixRegionSplitPolicy and DelimitedKeyPrefixRegionSplitPolicy
Status: Resolved | Priority: Major | Resolution: Won't Fix
Created: 28/Mar/21 07:57

Basically, I think we can use KeyPrefixRegionSplitPolicy and DelimitedKeyPrefixRegionSplitPolicy along with other split policies. In this Jira, we will support specifying a base split policy class in KeyPrefixRegionSplitPolicy and DelimitedKeyPrefixRegionSplitPolicy to use them with different split policies.
Bug: Add a new option in PE to indicate the current number of rows in the test table
Status: Open | Priority: Major | Resolution: 
Created: 10/Mar/21 07:32

When we have written 100000 rows in TestTable with 10 preSplits. Then we want to test asyncRandomRead, with 10 threads, per thread read 1000 rows. But the range of all read keys is in [0, 10000], all in the first region. It may cause hotspot problem, and the result is not accurate.

We can use --size and --rows in randomRead and randomSeekScan at the same time, so that the range of reading reaches the entire data set. But asyncRandomRead, scanRangeXX, sequentialRead and all the write still have hot spot problem.

This issue add a new option "initRows" to solve this problem.
Bug: Adding audit log for execMasterService
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 08/Feb/21 08:50

Hi:

I have found that in APIs, like execProcedure and execProcedureWithRet, have audit log to record who execute the master service. The log can be like:
{code:java}
LOG.info(master.getClientIdAuditPrefix() + " procedure request for: " + desc.getSignature());
{code}
But it seems that we forget to audit execMasterService. We should add one.
Bug: Backport HBASE-25665 to branch-1
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 17/Mar/21 04:27

Backport [https://github.com/apache/hbase/commit/ebb0adf50009fc133af0cfb0bdce4dfbb81d4fbf] for https://issues.apache.org/jira/browse/HBASE-25665 to branch-1
Bug: Shrink size of hbase-server module
Status: Open | Priority: Major | Resolution: 
Created: 17/Mar/21 17:49

Umbrella issue for shrinking the size of the hbase-server module. Its too big (see recent notes by [~zhangduo] that hbase-server size was making findbugs OOME).

Suggested candidate subtasks:

hbase-io
hbase-xtra-unit-tests <= Move large hbase-server tests out of hbase-server and into this module
hbase-region

HBASE-25190 was about an hbase-tool module
Bug: NPE getting metrics from standby masters (MetricsMasterWrapperImpl.getMergePlanCount)
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 25/Mar/21 00:00
Affects Version/s: 2.4.2

2021-03-24 23:26:15,828 ERROR [Timer for 'HBase' metrics system] impl.MetricsSourceAdapter: Error getting metrics from source Master,sub=Server
java.lang.NullPointerException
        at org.apache.hadoop.hbase.master.MetricsMasterWrapperImpl.getMergePlanCount(MetricsMasterWrapperImpl.java:58)
        at org.apache.hadoop.hbase.master.MetricsMasterSourceImpl.getMetrics(MetricsMasterSourceImpl.java:90)
        at org.apache.hadoop.metrics2.impl.MetricsSourceAdapter.getMetrics(MetricsSourceAdapter.java:200)
        at org.apache.hadoop.metrics2.impl.MetricsSystemImpl.snapshotMetrics(MetricsSystemImpl.java:419)
        at org.apache.hadoop.metrics2.impl.MetricsSystemImpl.sampleMetrics(MetricsSystemImpl.java:406)
        at org.apache.hadoop.metrics2.impl.MetricsSystemImpl.onTimerEvent(MetricsSystemImpl.java:381)
        at org.apache.hadoop.metrics2.impl.MetricsSystemImpl$4.run(MetricsSystemImpl.java:368)
        at java.base/java.util.TimerThread.mainLoop(Timer.java:556)
        at java.base/java.util.TimerThread.run(Timer.java:506)
Bug: Test failure: TestVerifyBucketCacheFile.testRetrieveFromFile
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 23/Mar/21 16:15
Affects Version/s: 2.3.4

Saw this test failure from 2.3 nightly.

https://ci-hadoop.apache.org/job/HBase/job/HBase%20Nightly/job/branch-2.3/190/testReport/junit/org.apache.hadoop.hbase.io.hfile.bucket/TestVerifyBucketCacheFile/health_checks___yetus_jdk8_hadoop2_checks___testRetrieveFromFile_1__blockSize_16_384__bucketSizes__I_371a67ec_/
h1. Regression

health checks / yetus jdk8 hadoop2 checks / org.apache.hadoop.hbase.io.hfile.bucket.TestVerifyBucketCacheFile.testRetrieveFromFile[1: blockSize=16,384, bucketSizes=[I@371a67ec]
Failing for the past 1 build (Since [!https://ci-hadoop.apache.org/static/e247241e/images/16x16/red.png! #190|https://ci-hadoop.apache.org/job/HBase/job/HBase%20Nightly/job/branch-2.3/190/] )
[Took 0.32 sec.|https://ci-hadoop.apache.org/job/HBase/job/HBase%20Nightly/job/branch-2.3/190/testReport/junit/org.apache.hadoop.hbase.io.hfile.bucket/TestVerifyBucketCacheFile/health_checks___yetus_jdk8_hadoop2_checks___testRetrieveFromFile_1__blockSize_16_384__bucketSizes__I_371a67ec_/history]
 
h3. Stacktrace

java.lang.AssertionError at org.apache.hadoop.hbase.io.hfile.bucket.TestVerifyBucketCacheFile.testRetrieveFromFile(TestVerifyBucketCacheFile.java:136)
Bug: ReplicationSourceWALReader log and handle exception immediately without retrying
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 09/Feb/21 07:14
Affects Version/s: 2.2.6

In [this piece of code about retrying in ReplicationSourceWALReader#run|https://github.com/apache/hbase/blob/0353909bc268e3ff3def098963d021e973f1f153/hbase-server/src/main/java/org/apache/hadoop/hbase/replication/regionserver/ReplicationSourceWALReader.java#L151], sleep time increases with the number of retries, if an exception happens that cannot be recovered by itself, error logs will appear after 12 hours (300 retries by default).
Bug: NPE when getting metrics of backup master
Status: Resolved | Priority: Major | Resolution: Duplicate
Created: 07/Jan/21 23:14
Affects Version/s: 2.4.0

Getting NullPointerException in MetricsMasterWrapperImpl.getMergePlanCount() when getting metrics via JMX on backup master. It appears due to the fact that regionNormalizerManager is null in backup masters as it's only initialized by HMaster.finishActiveMasterInitialization().
Bug: Bulkload replication HFileRefs cannot be cleared in some cases where set exclude-namespace/exclude-table-cfs
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 20/Feb/21 09:01
Affects Version/s: 2.2.6

In [ReplicationSource#addHFileRefs|https://github.com/apache/hbase/blob/ed90a14995acd87111d2b9849f07d84418ca43d4/hbase-server/src/main/java/org/apache/hadoop/hbase/replication/regionserver/ReplicationSource.java#L264], we may add unwanted hfiles to the _HFileRefs_ if a peer is set _replicate_all_ true and set _exclude-namespace/exclude-table-cfs_.

These unwanted _HFileRefs_ will not be replicated to remote cluster and not be cleared.

Two problems are caused by this bug:
 # The metric sizeOfHFileRefsQueue cannot be zeroed.
 # Referenced HFiles cannot be deleted by _ReplicationHFileCleaner._
Bug: asyncprofiler2.0 no longer supports svg; wants html
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 20/Mar/21 00:20

asyncprofiler2.0 is out. Its a nice tool. Unfortunately, it dropped the svg formatting option that we use in our servlet. Now it wants you  to pass html. Lets fix.

Old -o on asyncprofiler1.x
-o fmt            output format: summary|traces|flat|collapsed|svg|tree|jfr

New -o asyncprofiler 2.x
-o fmt            output format: flat|traces|collapsed|flamegraph|tree|jfr

If you pass svg to 2.0, it does nothing ... If you run the command hbase is running you see:

{code}
/tmp/prof-output$ sudo -u hbase /usr/lib/async-profiler/profiler.sh -e cpu -d 10 -o svg -f /tmp/prof-output/async-prof-pid-8346-cpu-1x.svg 8346
[ERROR] SVG format is obsolete, use .html for FlameGraph
{code}

At a minimum can make it so the OUTPUT param supports HTML. Here is current enum state:

{code}
  enum Output {
    SUMMARY,
    TRACES,
    FLAT,
    COLLAPSED,
    SVG,
    TREE,
    JFR
  }
{code}
Bug: HBase replication should have a metric to represent if the source is stuck getting initialized
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 03/Mar/21 04:13
Affects Version/s: 1.7.0

There can be situation when the cluster is not able to talk to peer cluster ZK, in that case, yes the logQueue will be accumulating but without digging into the logs, we cannot know what's the reason of loqQueue getting accumulating on the source. 

Since the replication source doesn't even start the shipper in this case, it is good to have a dedicated metric if the RS cannot talk to the peer's ZK at all. 

 
{code:java}
2021-03-03 04:02:10,704 DEBUG [peerId] zookeeper.RecoverableZooKeeper - Possibly transient ZooKeeper, quorum=zookeeper-0.zookeeper-a.fakeAddress:2181,zookeeper-1.zookeeper-a.fakeAddress:2181,zookeeper-2.zookeeper-a.fakeAddress:2181,zookeeper-3.zookeeper-a.fakeAddress:2181,zookeeper-4.zookeeper-a.fakeAddress:2181, exception=org.apache.zookeeper.KeeperException$AuthFailedException: KeeperErrorCode = AuthFailed for /hbase/hbaseid2021-03-03 04:02:10,704 DEBUG [peerId] zookeeper.RecoverableZooKeeper - Possibly transient ZooKeeper, quorum=zookeeper-0.zookeeper-a.fakeAddress:2181,zookeeper-1.zookeeper-a.fakeAddress:2181,zookeeper-2.zookeeper-a.fakeAddress:2181,zookeeper-3.zookeeper-a.fakeAddress:2181,zookeeper-4.zookeeper-a.fakeAddress:2181, exception=org.apache.zookeeper.KeeperException$AuthFailedException: KeeperErrorCode = AuthFailed for /hbase/hbaseidorg.apache.zookeeper.KeeperException$AuthFailedException: KeeperErrorCode = AuthFailed for /hbase/hbaseid at org.apache.zookeeper.KeeperException.create(KeeperException.java:126) at org.apache.zookeeper.KeeperException.create(KeeperException.java:54) at org.apache.zookeeper.ZooKeeper.exists(ZooKeeper.java:1119) at org.apache.hadoop.hbase.zookeeper.RecoverableZooKeeper.exists(RecoverableZooKeeper.java:284) at org.apache.hadoop.hbase.zookeeper.ZKUtil.checkExists(ZKUtil.java:469) at org.apache.hadoop.hbase.zookeeper.ZKClusterId.readClusterIdZNode(ZKClusterId.java:65) at org.apache.hadoop.hbase.zookeeper.ZKClusterId.getUUIDForCluster(ZKClusterId.java:96) at org.apache.hadoop.hbase.replication.HBaseReplicationEndpoint.getPeerUUID(HBaseReplicationEndpoint.java:104) at org.apache.hadoop.hbase.replication.regionserver.ReplicationSource.run(ReplicationSource.java:306)
{code}
Bug: Result#compareResults should compare tags.
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 01/Mar/21 19:33
Affects Version/s: 1.7.0

Today +Result#compareResults+ compares the 2 cells based on following parameters.
{noformat}
    for (int i = 0; i < res1.size(); i++) {
      if (!ourKVs[i].equals(replicatedKVs[i]) ||
          !CellUtil.matchingValue(ourKVs[i], replicatedKVs[i])) {
        throw new Exception("This result was different: "
            + res1.toString() + " compared to " + res2.toString());
      }
{noformat}

row, family, qualifier, timestamp, type, value.

We also need to compare tags to determine if both cells are equal or not.
Bug: Typo in docs vs code: hbase.mob.[file.]compaction.chore.period
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 16/Mar/21 22:30
Affects Version/s: 3.0.0-alpha-1

I might be missing something here, but after trying to disable mob compaction chore, and failed at it by setting hbase.mob.file.compaction.chore.period to 0, I realized docs and the code differ. 

Code:
https://github.com/apache/hbase/search?q=hbase.mob.compaction.chore.period
Docs:
https://github.com/apache/hbase/search?q=hbase.mob.file.compaction.chore.period

Looks like only a portion of the docs, still confusing.
Bug: Remove RSGroup test addition made in parent; depends on functionality not in old branches
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 16/Mar/21 20:07

TestRSGroupShell fails 100% of the time. See https://ci-hadoop.apache.org/view/HBase/job/HBase/job/HBase-Find-Flaky-Tests/job/branch-2.3/lastSuccessfulBuild/artifact/output/dashboard.html
Bug: move_namespaces_rsgroup should change hbase.rsgroup.name config in NamespaceDescriptor
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 12/Jan/21 04:59

move_namespaces_rsgroup command just move tables in this namespace to new rsgroup。when we create a table in this namespace，it  deploy on old rs group。
it maka some misunderstand for users。

move_namespaces_rsgroup should make the tables deployed on new rsgroup
Bug: Fix spotbugs warning in RoundRobinTableInputFormat
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 12/Mar/21 11:37

RoundRobinTableInputFormat.roundRobin(List) makes inefficient use of keySet iterator instead of entrySet iterator,

https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3043/2/artifact/yetus-general-check/output/branch-spotbugs-root-warnings.html