av9ash/GitBugs huggingface dataset:
Bug: Improve performance of HFileLinkCleaner by using ReadWriteLock instead of synchronize
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 05/Dec/20 13:42

HFileLinkCleaner uses synchronized method isFileDeletable, as a result, to cross the cleaner chain, all files will be processed serially. It may block the fork-join thread which scans out some archived files.
Bug: The stub in AsyncConnectionImpl.rsStubs and adminSubs never gets cleaned up
Status: Open | Priority: Major | Resolution: 
Created: 28/Nov/20 13:52

Currently there is no way for us to remove the unused stub in these two maps, and after HBASE-25292, things get worse as we will use ServerName directly as the stub key which means every time a region server restarts, we will have a new entry in the map.

In the past, since the name only contains host and port(and ip address if hostnameCanChange is true), so we will not have too many entris in these two maps unless we replaced the current region servers with new ones, but it could still be limited to the machines we have.

So here I propose that we just use host and port directly as now we will do a resolve when connecting, to get the old behavior back.

And maybe we should also find a way to cleanup these two maps.
Bug: [Flakey Tests] branch-2 TestMetaRegionLocationCache.testStandByMetaLocations
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 04/Dec/20 23:41

This just happened to me running tests locally. I see it in the current flakies list [https://ci-hadoop.apache.org/job/HBase/job/HBase-Flaky-Tests/job/branch-2/310/testReport/junit/org.apache.hadoop.hbase.client/TestMetaRegionLocationCache/testStandByMetaLocations/]

 

It looks like a simple timing issue. Let me put up a simple patch to see if it helps.
Bug: create-release scripts releasedocmaker step should be optional
Status: Open | Priority: Major | Resolution: 
Created: 04/Dec/20 17:40

The create-release scripts assume, when invoking releasedocmaker and performing surgery on CHANGES.md and RELEASENOTES.md during the 'tag' stage, that the current RC step is RC0. The entirety of the generated CHANGES.md and RELEASENOTES.md files are stitched in at the head, just below the ASF notice. If we are at a RC step that is not zero, wouldn't this duplicate all CHANGES.md and RELEASENOTES.md content for the release? There would be all the content added for RC0, then the same content (with delta) added for RC1, and so on. 

For this reason the releasedocmaker invocation should itself be optional.

For RC steps > 0, assume the RM has updated CHANGES.md and RELEASENOTES.md to reflect the delta.
Bug: [Flakey Tests] branch-2 TestRefreshRecoveredReplication.testReplicationRefreshSource:141 Waiting timed out after [60,000] msec
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 02/Dec/20 04:32

This one fails for me most times running locally.

I added some debug (see the PR).

In the test we look for old replication source to be non-zero long after it has been processed. The test gets stuck waiting.

See here is where the table becomes available, after which we start expecting the old source replication queue to be non-zero.

{{ 2020-12-01 20:02:52,400 INFO [Listener at localhost/56996] regionserver.TestRefreshRecoveredReplication(136): Available testReplicationRefreshSource}}

 But see here where the replication source has been removed before we get to the 'available' line above:

{{2020-12-01 20:02:50,768 INFO [ReplicationExecutor-0.replicationSource,2-kalashnikov.attlocal.net,56950,1606881738045.replicationSource.shipperkalashnikov.attlocal.net%2C56950%2C1606881738045,2-kalashnikov.attlocal.net,56950,1606881738045] regionserver.ReplicationSourceManager(463): Done with the recovered queue 2-kalashnikov. attlocal.net,56950,1606881738045}}{{ }}
Bug: [Flakey Tests] branch-2 TestReadReplicas#testVerifySecondaryAbilityToReadWithOnFiles
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 30/Nov/20 21:44

This test fails for me locally every time. Looking at TestReadReplicas, a few do a reset of the cluster after some configuration. Let me just break these out to be their own test. When I do this, the test that fails for me starts passing.
Bug: ThreadLocal pooling leads to NullPointerException
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 19/Nov/20 11:14
Affects Version/s: 3.0.0-alpha-1

We got NPE after setting {{hbase.client.ipc.pool.type}} to {{thread-local}}:
{noformat}
20/11/18 01:53:04 ERROR yarn.ApplicationMaster: User class threw exception: java.lang.NullPointerException
java.lang.NullPointerException
        at org.apache.hadoop.hbase.ipc.AbstractRpcClient.close(AbstractRpcClient.java:496)
        at org.apache.hadoop.hbase.client.ConnectionImplementation.close(ConnectionImplementation.java:1944)
        at org.apache.hadoop.hbase.mapreduce.TableInputFormatBase.close(TableInputFormatBase.java:660)
{noformat}
The root cause of the issue is probably at {{PoolMap.ThreadLocalPool.values()}}:
{code:java}
public Collection<R> values() {
  List<R> values = new ArrayList<>();
  values.add(get());
  return values;
}
{code}
It adds {{null}} into the collection if the current thread does not have any resources which leads to NPE later.

I traced the usages of values() and it should return every resource, not just that one which is attached to the caller thread.
Bug: Fix ErrorProne error which causes nightly to fail
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 29/Nov/20 14:47

{noformat}
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:testCompile (default-testCompile) on project hbase-server: Compilation failure
[ERROR] /home/jenkins/jenkins-home/workspace/HBase_HBase_Nightly_master/component/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestHRegion.java:[7536,38] error: [ArrayToString] Calling toString on an array does not provide useful information
[ERROR]     (see https://errorprone.info/bugpattern/ArrayToString)
[ERROR]   Did you mean 'fail("the qualifier " + Arrays.toString(q1) + " should be " + v1 + " or " + v2 + ", but " + q1Value);'?
[ERROR] -> [Help 1]
{noformat}
Bug: The sort icons not shown after Upgrade JQuery to 3.5.1
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 23/Nov/20 16:32

The sort icons not shown after Upgrade JQuery to 3.5.1:

Upgrade has changes on tablesorter class values. Need to change in hbase.css accordingly.

header changed to tablesorter-header
headerSortUp changed to tablesorter-headerAsc
headerSortDown changed to tablesorter-headerDesc
Bug: 'hbase master stop' shuts down the cluster, not the master only
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 02/Nov/20 23:24

This is confusing (an operator at place-of-employment shut down a massive cluster mistakenly thinking he was shutting down the master only).

If I run 'hbase master --help', it says unsupported and then dumps out:
{code:java}
org.apache.hbase.thirdparty.org.apache.commons.cli.UnrecognizedOptionException: Unrecognized option: --help
 at org.apache.hbase.thirdparty.org.apache.commons.cli.Parser.processOption(Parser.java:383)
 at org.apache.hbase.thirdparty.org.apache.commons.cli.Parser.parse(Parser.java:210)
 at org.apache.hbase.thirdparty.org.apache.commons.cli.Parser.parse(Parser.java:88)
 at org.apache.hadoop.hbase.master.HMasterCommandLine.run(HMasterCommandLine.java:89)
 at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:76)
 at org.apache.hadoop.hbase.util.ServerCommandLine.doMain(ServerCommandLine.java:149)
 at org.apache.hadoop.hbase.master.HMaster.main(HMaster.java:2945)
Usage: Master [opts] start|stop|clear
 start Start Master. If local mode, start Master and RegionServer in same JVM
 stop Start cluster shutdown; Master signals RegionServer shutdown
 clear Delete the master znode in ZooKeeper after a master crashes
 where [opts] are:
 --minRegionServers=<servers> Minimum RegionServers needed to host user tables.
 --localRegionServers=<servers> RegionServers to start in master process when in standalone mode.
 --masters=<servers> Masters to start in this process.
 --backup Master should start in backup mode{code}
 

... so the 'help' is clear that its the cluster that goes down, not just the master – but that is hardly compensates for the unexpected behavior.

 

'hbase master stop' is actually what is used internally you run stop-hbase.sh.

 

Stopping the cluster when your run 'hbase master stop' is actually very old behavior. Its still confusing though. We could change this.

If I run 'hbase regionserver stop', it does this:
{code:java}
System.err.println(
  "To shutdown the regionserver run " +
  "hbase-daemon.sh stop regionserver or send a kill signal to " +
  "the regionserver pid");{code}
I'd think we could make improvement here. We could do something like the RS output if user types 'hbase master stop' at a minimum requiring operator add a '–force' flag if they want the cluster to go down or point them to a new hbase cluster stop/hbase cluster start or point them at stop-hbase.sh.  Should also change mode so 'hbase master stop' stops the master and not the cluster (there was no stopMaster when the 'hbase master stop' was added originally – but there is one now).
Bug: Change encryption key generation algorithm used in the HBase shell
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 10/Nov/20 09:09

This PR is a follow-up of HBASE-25181 (#2539), where several issues were discussed on the PR:

1. Currently we use {{PBKDF2WithHmacSHA1}} key generation algorithm to generate a secret key for HFile / WalFile encryption, when the user is defining a string encryption key in the hbase shell. This algorithm is not secure enough and not allowed in certain environments (e.g. on FIPS compliant clusters). We are changing it to {{PBKDF2WithHmacSHA384}}. It will not break backward-compatibility, as even the tables created by the shell using the new algorithm will be able to load (e.g. during bulkload / replication) the HFiles serialized with the key generated by an old algorithm, as the HFiles themselves already contain the key necessary for their decryption.

Smaller issues to be fixed:

2. Improve the documentation e.g. with the changes introduced by HBASE-25181 and also by some points discussed on the Jira ticket of HBASE-25263.

3. In {{EncryptionUtil.createEncryptionContext}} the various encryption config checks should throw {{IllegalStateExceptions}} instead of {{RuntimeExceptions}}.

4. Test cases in {{TestEncryptionTest.java}} should be broken down into smaller tests.

5. {{TestEncryptionDisabled.java}} should use {{ExpectedException}} JUnit rule to validate exceptions.
Bug: [branch-1] Fix two methods removed problems reported by compat-check
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 15/Nov/20 10:18

{code}
hbase-server-1.6.0.jar, RpcServerInterface.class
package org.apache.hadoop.hbase.ipc
RpcServerInterface.refreshAuthManager ( PolicyProvider p1 ) [abstract]  :  void

hbase-server-1.6.0.jar, Store.class
package org.apache.hadoop.hbase.regionserver
Store.createWriterInTmp ( long p1, Compression.Algorithm p2, boolean p3, boolean p4, boolean p5, boolean p6 ) [abstract]  :  StoreFile.Writer
Store.createWriterInTmp ( long p1, Compression.Algorithm p2, boolean p3, boolean p4, boolean p5, boolean p6, TimeRangeTracker p7 ) [abstract]  :  StoreFile.Writer
{code}

These two removed methods may be problematic, let's review them again.
Bug: Scan#setRowPrefixFilter Unexpected behavior
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 17/Nov/20 12:50

e.g.

startRow : "112"

rowPrefixFilter : "11"

The Result of this scan might contains : "111", which unexpected.
{code:java}
  public Scan setRowPrefixFilter(byte[] rowPrefix) {
    if (rowPrefix == null) {
      setStartRow(HConstants.EMPTY_START_ROW);
      setStopRow(HConstants.EMPTY_END_ROW);
    } else {
      this.setStartRow(rowPrefix);
      this.setStopRow(calculateTheClosestNextRowKeyForPrefix(rowPrefix));
    }
    return this;
  }
{code}
 Scan#setRowPrefixFilter achieves this function by setting startRow and stopRow, ignoring the situation that startRow may have been set.
Bug: Enable configuration based enable/disable of Unsafe package usage
Status: Open | Priority: Major | Resolution: 
Created: 06/Nov/20 01:05

We need a provide away for clients to disable Unsafe package usage . Currently there is no way for clients to specify that they don't want to use Unsafe conversion for Bytes conversion.

As a result there could be some issues with missing methods of Unsafe when client is on JDK 11 . So the clients can disable Unsafe package use and use normal conversion if they want to.

Also we use static references to Unsafe Availability in Bytes class assuming that the Unsafe availability is set during class loading and no one can ever override it later. Now that we plan to expose a util for clients to override the availability if required, we need to avoid the static references for computing the availability whenever we do the comparisions
Bug: ui throws NPE
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 20/Nov/20 09:11
Affects Version/s: 2.2.3

https://github.com/apache/hbase/blob/eca904e0fb438461a8da3f37cea3eaf496988be9/hbase-server/src/main/java/org/apache/hadoop/hbase/master/HMaster.java#L3624

 if rs has invalid znode, and restart master, ui will throw NPE.
i encountered this problem during the upgrade.

workaround: restart HBase.
Bug: [meta replicas] ArrayIndexOutOfBoundsException in ZKConnectionRegistry
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 12/Nov/20 21:53
Affects Version/s: HBASE-18070

ITBLL Testing HBASE-18070 feature, [~huaxiangsun] found this:
{code:java}
2020-11-12 19:48:12,358 ERROR org.apache.hadoop.hbase.util.FutureUtils: Unexpected error caught when processing CompletableFuturejava.lang.ArrayIndexOutOfBoundsException: Index 3 out of bounds for length 3     at org.apache.hadoop.hbase.client.ZKConnectionRegistry.lambda$getMetaRegionLocation$2(ZKConnectionRegistry.java:180)     at org.apache.hadoop.hbase.util.FutureUtils.lambda$addListener$0(FutureUtils.java:68)     at java.base/java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:859)     at java.base/java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:837)     at java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)     at java.base/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)     at org.apache.hadoop.hbase.client.ZKConnectionRegistry.lambda$getAndConvert$0(ZKConnectionRegistry.java:78)     at org.apache.hadoop.hbase.util.FutureUtils.lambda$addListener$0(FutureUtils.java:68)     at java.base/java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:859)     at java.base/java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:837)     at java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)     at java.base/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)     at org.apache.hadoop.hbase.zookeeper.ReadOnlyZKClient$ZKTask$1.exec(ReadOnlyZKClient.java:174)     at org.apache.hadoop.hbase.zookeeper.ReadOnlyZKClient.run(ReadOnlyZKClient.java:342)    at java.base/java.lang.Thread.run(Thread.java:834) {code}
The code has been this way a long time but his running with four replicas seems to have revealed a race exposed by using replicaid as index.
Bug: branch-1 docker mode for yetus fails
Status: Resolved | Priority: Major | Resolution: Duplicate
Created: 20/Nov/20 22:14

{noformat}
15:30:41  Step 28/33 : RUN gem install rubocop:'<= 0.81'
15:30:41   ---> Running in 21103fb7944c
15:30:42  Building native extensions.  This could take a while...
15:30:43  [91mERROR:  Error installing rubocop:
15:30:43  	parallel requires Ruby version >= 2.5.
15:30:43  [0mSuccessfully installed jaro_winkler-1.5.4
15:30:44  The command '/bin/sh -c gem install rubocop:'<= 0.81'' returned a non-zero code: 1
15:30:44  ERROR: Docker failed to build yetus/hbase:b249092a5f. 
{noformat}
Bug: HBASE-18070 makes for NPEs in some hbase-backup tests on master
Status: Open | Priority: Major | Resolution: 
Created: 20/Nov/20 08:23

Let me work on this as a distinct issue. The hbase-backup tests are complex/massive so need to do some study. Its the jdk8 runs that fail. [https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2643/] jdk11 passes.  All pass locally too.
Bug: Follow-on: defend against read replicas being enabled for server-side clients 
Status: Open | Priority: Major | Resolution: 
Created: 17/Nov/20 00:29

A nice aid for operators would be to spend some time on ensuring that at least 'LoadBalance' is not set for the clients that on the serverside inside Master in particular. Currently our only defense is documentation. An operator might set them for client-side and server-side by mistake. Defend server-side clients against this possibility to avoid Master making decisions based off stale state.
Bug: Follow-on tasks that came of "HBASE-18070 Enable memstore replication for meta replica"
Status: Open | Priority: Major | Resolution: 
Created: 20/Nov/20 23:10

The HBASE-18070 _Enable memstore replication for meta replica_ 
turned up _follow-ons:_ tests, doc, guardrails and enhancements. Let me give them their own issue so they do not crowd the original and so I can resolve the original against the version that carries the first implementation of the enhancement (Want to avoid the alternative of an issue that stays open for ever).
Bug: The log in SimpleLoadBalancer#onConfigurationChange is wrong
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 19/Nov/20 08:59
Affects Version/s: 2.2.7

[https://github.com/apache/hbase/blob/8c1e4763b3e11d4553e5a59e620ab30e3b2047e9/hbase-server/src/main/java/org/apache/hadoop/hbase/master/balancer/SimpleLoadBalancer.java#L139]

current overallSlop should be "overallSlop"
Bug: Upgrade Bootstrap to 3.4.1
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 10/Nov/20 07:25

HBase UI is currently using bootstrap 3.3.7. This version is vulnerable to 4 medium CVEs (CVE-2018-14040, CVE-2018-14041, CVE-2018-14042, and CVE-2019-8331). Details on all the bootstrap versions and vulnerabilities is here: [https://snyk.io/vuln/npm:bootstrap]

Upgrading to bootstrap 4 would be nice, but potentially more work to do. To avoid these CVE issues, we should at least upgrade to the latest bootstrap 3, which is 3.4.1 currently.
Bug: Refactor the locate WAL logic in ReplicationSource
Status: Open | Priority: Major | Resolution: 
Created: 17/Nov/20 01:09

When cluster replication enabled and one RegionServer crashed, its WALs will be move from WALs dir to oldWALs dir and its replication queue will moved to other RegionServer's replication queue.
 
HDFS layout (WAL Storage)
/hbase/WALs/RS1/1.log
/hbase/WALs/RS1/2.log
/hbase/WALs/RS1/3.log
ZooKeeper layout (Replication queue storage)
/hbase/replication/rs/RS1/peerId/1.log
/hbase/replication/rs/RS1/peerId/2.log
/hbase/replication/rs/RS1/peerId/3.log
 
Failover finished:
HDFS layout (WAL Storage)
/hbase/.oldWALs/1.log
/hbase/.oldWALs/2.log
/hbase/.oldWALs/3.log
ZooKeeper layout (Replication queue storage)
/hbase/replication/rs/RS2/peerId-RS1/1.log
/hbase/replication/rs/RS2/peerId-RS1/2.log
/hbase/replication/rs/RS2/peerId-RS1/3.log
 
And if enabled hbase.separate.oldlogdir.by.regionserver, the HDFS layout may be:
HDFS layout (WAL Storage)
/hbase/.oldWALs/RS1/1.log
/hbase/.oldWALs/RS1/2.log
/hbase/.oldWALs/RS1/3.log
 
Then if RS2 crashed, the HDFS layout will not change but ZooKeeper layout may changed.
ZooKeeper layout (Replication queue storage)
/hbase/replication/rs/RS3/peerId-RS1-RS2/1.log
/hbase/replication/rs/RS3/peerId-RS1-RS2/2.log
/hbase/replication/rs/RS3/peerId-RS1-RS2/3.log
 
So even the replication queue was transfered many times, the HDFS layout never change.
 
Another case is master-cluster disaster, the failover work not finished. Then ReplicationSyncUp tool can start replication source to replicate the WAL data. The HDFS layout need to consider two more case:
/hbase/WALs/RS1/1.log
/hbase/WALs/RS1/2.log
/hbase/WALs/RS1/3.log
or
/hbase/WALs/RS1-splitting/1.log
/hbase/WALs/RS1-splitting/2.log
/hbase/WALs/RS1-splitting/3.log
Bug: Add SSL keystore type and truststore related configs for HBase RESTServer
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 10/Nov/20 15:22

The RESTServer currently relies on the following parameters to configure SSL on the REST API:
 * {{hbase.rest.ssl.enabled}}
 * {{hbase.rest.ssl.keystore.store}}
 * {{hbase.rest.ssl.keystore.password}}
 * {{hbase.rest.ssl.keystore.keypassword}}
 * {{hbase.rest.ssl.exclude.cipher.suites}}
 * {{hbase.rest.ssl.include.cipher.suites}}
 * {{hbase.rest.ssl.exclude.protocols}}
 * {{hbase.rest.ssl.include.protocols}}

In this patch I want to introduce the following new parameters:
 * {{hbase.rest.ssl.keystore.type}}
 * {{hbase.rest.ssl.truststore.store}}
 * {{hbase.rest.ssl.truststore.password}}
 * {{hbase.rest.ssl.truststore.type}}

If any of the new the parameter is not provided, then we should fall-back to the current behaviour (e.g. assuming JKS keystore/truststore types, or no passwords, or no custom trust store file).
Bug: Need to throw the original exception in HRegion#openHRegion
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 12/Nov/20 01:50

{code:java}
protected HRegion openHRegion(final CancelableProgressable reporter)
throws IOException {
  try {
    ......
  } catch(Throwable t) {
    // By coprocessor path wrong region will open failed,
    // MetricsRegionWrapperImpl is already init and not close,
    // add region close when open failed
    this.close(); // This may throw IOException too.
    throw t;
  }
  return this;
}
{code}
https://github.com/apache/hbase/blob/master/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java#L8144

this.close() may throw IOException too. The original exception will not be recorded.
Bug: Add options for disabling column family encryption and choosing hash algorithm for wrapped encryption keys.
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 13/Oct/20 08:40
Affects Version/s: 2.3.2

Currently we are using MD5 hash algorithm to store a hash for encryption keys. This hash is needed to verify the secret key of the subject. (e.g. making sure that the same secret key is used during encrypted HFile / WalFile read and write). The MD5 algorithm is considered weak, and can not be used in some (e.g. FIPS compliant) clusters. However, currently it is not possible to use different hash algorithm, or to disable the whole column family encryption globally on the cluster.

In this patch:

* I introduce a backward compatible way of specifying the hash algorithm. This enable us to use newer and/or more secure hash algorithms like SHA-384 or SHA-512 (which are FIPS compliant).
* I added a configuration parameter to globally enable / disable the column family encryption feature. (enabled by default for backward compatibility). This is handy if someone wants to operate an HBase cluster making sure that uses are only relying on other (e.g. HDFS based) encryption mechanisms.
Bug: The client zk syncer should deal with meta replica count change
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 26/Oct/20 03:00

The failure of TestSeparateClientZKCluster is because that, we start the zk syncer before we initialize meta region, and after HBASE-25099, we will scan zookeeper to get the meta znodes directly instead of checking the config, so we will get an empty list since there is no meta location on zk yet, thus we will sync nothing.

But changing the order can not solve everything, as after HBASE-25099, we can change the meta replica count without restartinig master, so the zk syncer should have the ability to know the change and start to sync the location for the new replicas.