av9ash/GitBugs huggingface dataset:
Bug: [JDK17] Fix Failure TestLdapHttpServer
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 02/Feb/24 00:18

TestLdapHttpServer is failing with JDK17 because of internal APIs usage.
{code:java}
[INFO] Running org.apache.hadoop.hbase.http.TestLdapHttpServer
[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 7.18 s <<< FAILURE! - in org.apache.hadoop.hbase.http.TestLdapHttpServer
[ERROR] org.apache.hadoop.hbase.http.TestLdapHttpServer  Time elapsed: 7.165 s  <<< ERROR!
java.lang.IllegalAccessError: class org.apache.directory.server.core.security.CertificateUtil (in unnamed module @0x25bbf683) cannot access class sun.security.x509.X500Name (in module java.base) because module java.base does not export sun.security.x509 to unnamed module @0x25bbf683
	at org.apache.directory.server.core.security.CertificateUtil.createTempKeyStore(CertificateUtil.java:334)
	at org.apache.directory.server.factory.ServerAnnotationProcessor.instantiateLdapServer(ServerAnnotationProcessor.java:158)
	at org.apache.directory.server.factory.ServerAnnotationProcessor.createLdapServer(ServerAnnotationProcessor.java:318)
	at org.apache.directory.server.factory.ServerAnnotationProcessor.createLdapServer(ServerAnnotationProcessor.java:351)
	at org.apache.directory.server.core.integ.CreateLdapServerRule$2.evaluate(CreateLdapServerRule.java:112)
	at org.apache.directory.server.core.integ.CreateDsRule$2.evaluate(CreateDsRule.java:124)
	at org.junit.rules.RunRules.evaluate(RunRules.java:20)
	at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:316)
	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:240)
	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:214)
	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:155)
	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:385)
	at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162)
	at org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:507)
	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:495)

[INFO] 
[INFO] Results:
[INFO] 
[ERROR] Errors: 
[ERROR]   TestLdapHttpServer » IllegalAccess class org.apache.directory.server.core.security.CertificateUtil (in unnamed module @0x25bbf683) cannot access class sun.security.x509.X500Name (in module java.base) because module java.base does not export sun.security.x509 to unnamed module @0x25bbf683
[INFO] 
[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0

{code}

Adding following to jvn flags works.
{code}
+      --add-opens java.base/sun.security.x509=ALL-UNNAMED
+      --add-opens java.base/sun.security.util=ALL-UNNAMED
{code}
Bug: Positive connection test in TestShadeSaslAuthenticationProvider runs with Kerberos instead of Shade authentication
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 30/Jan/24 21:10
Affects Version/s: 2.4.17

The positive test (testPositiveAuthentication) in TestShadeSaslAuthenticationProvider doesn't create a new user in user1.doAs(), so it will use the already Kerberos authenticated user instead of re-authenticating with the token. 

As a consequence it doesn't reveal a problem introduced with HBASE-23881 which will cause clients to timeout if authenticated with a SASL mech which doesn't create a reply token in case of successful authentication.
Bug: Output hbase logs to working directory in client integration test
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 25/Jan/24 06:23

So we can see them in the job artifacts, currently it will be logged to hbase install directory which is outside the working dir so we can not see them.

The client integration test for master branch is failing because can not start hbase cluster, we need the logs to find out the root cause.
Bug: Close HBase connection on exit from HBase Shell
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 06/Feb/24 15:18
Affects Version/s: 2.4.17

When using Netty for the ZK client, hbase shell hangs on exit.
This is caused by the non-deamon Netty threads that ZK creates.

Wheter ZK should create daemon threads for Netty or not is debatable, but explicitly closing the connection in hbase shell on exit fixes the issue.
Bug: Multi should return what results it can before rpc timeout
Status: Open | Priority: Major | Resolution: 
Created: 07/Feb/24 13:39

Scans have a nice feature where they try to return a heartbeat with whatever results they have accumulated before the rpc timeout expires. It targets returning in 1/2 the rpc timeout or max scanner time. The reason for scans is to avoid painful scanner timeouts which cause the scan to have to be restarted due to out of sync sequence id.

Multis have a similar problem. A big batch can come in which can't be served in the configured timeout. In this case the client side will abandon the request when the timeout is exceeded, and resubmit if there are retries/operation timeout left. This wastes work since it's likely that some of the results had been fetched by the time a timeout occurred.

Multis already can retry immediately when the batch exceeds the max result size limit. We can use the same functionality to also return when we've taken more than half the rpc timeout.
Bug: Update ref guide about isolation guarantees for scans
Status: Open | Priority: Major | Resolution: 
Created: 07/Feb/24 02:40

In the "Consistency of Scans" section of [https://hbase.apache.org/acid-semantics.html,] there is some confusing and outdated information. First it's hard to realize that it's specifically talking about consistency across rows. Secondly, it's outdated because in modern hbase we acquire and maintain a memstore readPt for the lifetime of a scan in a region. So we should retain read committed behavior across rows, at least within the scope of a region.
Bug: Add comment  around erasure coding policy in DEFAULT_VALUE map
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 29/Jan/24 14:40

New description: Upon investigation, we realized that it's necessary to put ERASURE_CODING_POLICY in the DEFAULT_VALUES map so that when the TableDescriptor is printed as a string, that setting is not listed as METADATA. We added a comment to note that for future reference.

Old description: With ERASURE_CODING_POLICY, the default value is null (no policy). I added a record of that in DEFAULT_VALUES, because other settings seemed to do that.

A null value is never stored on a HTD because our code handles removing from map when setting null. So we'd never have an opportunity to match against the DEFAULT_VALUE. If someone tried setting a string value "null", that would fail validation because it's not a valid policy. So there's no reason to record this default value. It doesn't cause a problem, but is confusing to anyone reading the code. Remove it.
Bug: Write codec class into hfile header/trailer
Status: Open | Priority: Major | Resolution: 
Created: 05/Feb/24 21:46

We recently started playing around with the new bundled compression libraries as of 2.5.0. Specifically, we are experimenting with the different zstd codecs. The book says that aircompressor's zstd is not data compatible with hadoops, but doesn't say the same about zstd-jni.

In our experiments we ended up in a state where some hfiles were encoded with zstd-jni (zstd.ZstdCodec) while others were encoded with hadoop (ZStandardCodec). At this point the cluster became extremely unstable, with some files unable to be read because they encoded with a codec that didn't match the current runtime configration. Changing the runtime configuration caused the other files to not be readable.

I think this problem could be solved by writing the classname of the codec used into the hfile. This could be used as a hint so that a regionserver can read hfiles compressed with any compression codec that it supports.

[~apurtell] do you have any thoughts here since you brought us all of these great compression options?
Bug: HBaseReplicationEndpoint creates new ZooKeeper client every time it tries to reconnect
Status: Resolved | Priority: Major | Resolution: Invalid
Created: 01/Feb/24 16:20
Affects Version/s: 2.4.17

Asbtract base class {{HBaseReplicationEndpoint}} and therefore {{HBaseInterClusterReplicationEndpoint}} creates new ZooKeeper client instance every time there's an error occurs in communication and it tries to reconnect. This was not a problem with ZooKeeper 3.4.x versions, because the TGT Login thread was a static reference and only created once for all clients in the same JVM. With the upgrade to ZooKeeper 3.5.x the login thread is dedicated to the client instance, hence we have a new login thread every time the replication endpoint reconnects.
{code:java}
/**
 * A private method used to re-establish a zookeeper session with a peer cluster.
 */
protected void reconnect(KeeperException ke) {
  if (
    ke instanceof ConnectionLossException || ke instanceof SessionExpiredException
      || ke instanceof AuthFailedException
  ) {
    String clusterKey = ctx.getPeerConfig().getClusterKey();
    LOG.warn("Lost the ZooKeeper connection for peer " + clusterKey, ke);
    try {
      reloadZkWatcher();
    } catch (IOException io) {
      LOG.warn("Creation of ZookeeperWatcher failed for peer " + clusterKey, io);
    }
  }
}{code}
{code:java}
/**
 * Closes the current ZKW (if not null) and creates a new one
 * @throws IOException If anything goes wrong connecting
 */
synchronized void reloadZkWatcher() throws IOException {
  if (zkw != null) zkw.close();
  zkw = new ZKWatcher(ctx.getConfiguration(), "connection to cluster: " + ctx.getPeerId(), this);
  getZkw().registerListener(new PeerRegionServerListener(this));
} {code}
If the target cluster of replication is unavailable for some reason, the replication endpoint keeps trying to reconnect to ZooKeeper destroying and creating new Login threads constantly which will carpet bomb the KDC host with login requests.
 
I'm not sure how to fix this yet, trying to create a unit test first.
Bug: Refactor TestClientTimeouts to make it more clear that what we want to test
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 26/Jan/24 04:01

In HBASE-23647, we change the default registry to rpc based, so it could also fail when setting up connection when we inject a timeout rpc client, but actually we just want to test timeout for admin methods, so we'd better refactor the test a bit to make it more clear that the failure for master setup is not important.
Bug: TestUnknownServers.testListUnknownServers is flaky in branch-2
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 25/Jan/24 11:18
Affects Version/s: 2.5.7

{code:java}
[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.913 s <<< FAILURE! - in org.apache.hadoop.hbase.master.TestUnknownServers
[ERROR] org.apache.hadoop.hbase.master.TestUnknownServers.testListUnknownServers  Time elapsed: 0.204 s  <<< FAILURE!
java.lang.AssertionError: expected:<1> but was:<2> {code}
The value of TestUnknownServers.SLAVES is different between [branch-2|https://github.com/apache/hbase/blob/68bc533f7116cedc681704b82319e5793b827621/hbase-server/src/test/java/org/apache/hadoop/hbase/master/TestUnknownServers.java#L44] and [master|https://github.com/apache/hbase/blob/b87b05c847f00c292664d894c21f83c73d48460d/hbase-server/src/test/java/org/apache/hadoop/hbase/master/TestUnknownServers.java#L43].

It is 1 in master but 2 in branch-2.

The RegionServer marked UNKNOWN_SERVER is the one that *holds regions* but is not tracked by the ServerManager.

Please see HMaster.getUnknownServers
{code:java}
private List<ServerName> getUnknownServers() {
  if (serverManager != null) {
    final Set<ServerName> serverNames = getAssignmentManager().getRegionStates().getRegionStates()
      .stream().map(RegionState::getServerName).collect(Collectors.toSet());
    final List<ServerName> unknownServerNames = serverNames.stream()
      .filter(sn -> sn != null && serverManager.isServerUnknown(sn)).collect(Collectors.toList());
    return unknownServerNames;
  }
  return null;
} {code}
In UT TestUnknownServers.testListUnknownServers, we start a HBase cluster with 2 RegionServer, if all region are assigned to ONE server, then only that server is called UNKNOWN_SERVER, the UT will fail.
Bug: Remove noisy WARN from trying to construct MetricsServlet
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 16/Jan/24 16:53
Affects Version/s: 3.0.0-beta-1

MetricsServlet is deprecated since hadoop 2.8 and removed in hadoop3. In HBASE-20904 the servlet initialization was refactored, and we now have a noisy WARN (with stacktrace) when MetricsServlet does not exist. This should be common, since hadoop3 is the modern version to run on (hadoop2 almost EOL). We shouldn't warn.

Fix the code to not produce a warn when MetricsServlet is not available.
Bug: Add remove(String key, Metric metric) method to MetricRegistry interface
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 24/Jan/24 20:37

Add a `remove(String name, Metric metric)` method to the `MetricRegistry` interface. Right now the interface only contains a `remove(String name)` method.

This additional remove method will give users the power to remove a `Metric` with the specified `name` from the metric registry if and only if the provided `metric` matches the object in the registry.

Implementing the new `remove(String name, Metric metric)` should be straight forward because the `MetricRegistryImpl` class stores metrics in a `ConcurrentMap`, which already contains a `remove(Object key, Object value)` method

This change will not be a breaking one because the interface is marked with `@IntefaceStability.Evolving`

[~rmdmattingly]
Bug: Add tracking of fs read times in ScanMetrics and slow logs
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 10/Jan/24 14:43

We've had this in our production for a while, and it's useful info to have. We already track FS read times in [HFileBlock|https://github.com/apache/hbase/blob/master/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/HFileBlock.java#L1828-L1831C10]. We can project that into the ScanMetrics instance and slow log pretty easily. It is also helpful to add a slow.fs.read.threshold, over which we log a warn
Bug: The bad auth exception can not be passed to client rpc calls properly
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 15/Jan/24 04:15

Found this when implementing HBASE-25051.

Basically there are 2 problems:

# IPCUtil.isFatalConnectionException only checks whether class name matches, so if we use a sub class for FatalConnectionException, it will return false which makes the logic incorrect.
# In BlockingRpcConnection, we will first check whether there is a call with the id but since we will pass -1 as call id for bad preamble header, we will return earlier without actually checking the error response.

This will not introduce big trouble in production as the call will still fail with connection closed exception, but still worth to fix, anyway.
Bug: Add property to customize Version information
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 12/Jan/24 20:06

In hbase-common we generate Version.java using the ${project.version} property. In some custom builds, it may be necessary to override the project version. The custom version may not be compatible with how Version works, or the user may want to add extra metadata (like a build number). We can add a property which defaults to ${project.version} but allows the user to specify separately if desired.
Bug: Expose DelegatingRpcScheduler as IA.LimitedPrivate
Status: Resolved | Priority: Major | Resolution: Duplicate
Created: 17/Jan/24 17:26

We have DelegatingRpcScheduler in src/test of hbase-server. RpcScheduler itself is IA.LimitedPrivate, and in 2.6.0 we are pushing an incompatible change from HBASE-27144.

We can limit the impact of breaking changes like this by exposing DelegatingRpcScheduler to users. Users can extend this class and only override the pieces that they care about, thus reducing the surface area of compatibility issues.
Bug: Expose DelegatingRpcScheduler as IA.LimitedPrivate
Status: Resolved | Priority: Major | Resolution: Duplicate
Created: 17/Jan/24 17:27

We have DelegatingRpcScheduler in src/test of hbase-server. RpcScheduler itself is IA.LimitedPrivate, and in 2.6.0 we are pushing an incompatible change from HBASE-27144.

We can limit the impact of breaking changes like this by exposing DelegatingRpcScheduler to users. Users can extend this class and only override the pieces that they care about, thus reducing the surface area of compatibility issues.
Bug: Sending compact request if necessary after flushing at server side
Status: Open | Priority: Major | Resolution: 
Created: 08/Jan/24 12:41

By default, hbase would automatically compact periodically.
However, In this period, what we flush frequently would cause many hfile genereated, and hbase does not compact until the next period.

So in order to prevent the rapid growth of the number of hfile under some conditions, I think we can add a check if it needs to compact after flushing region at server side.

Do you think it's a better way?  thanks!
 
One of the codes in here:
{code:java}
//FlushRegionCallable.java  doCall()
try {
  HRegion.FlushResult res;
  if (columnFamilies == null) {
    res = region.flush(true);
  } else {
    res = region.flushcache(columnFamilies, false, FlushLifeCycleTracker.DUMMY);
  }
  if (res.getResult() == HRegion.FlushResult.Result.CANNOT_FLUSH) {
    throw new IOException("Unable to complete flush " + regionInfo);
  }

{code}
Bug: [hbase-thirdparty] Upgrade Netty to 4.1.104.Final
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 04/Jan/24 18:45

There is a CVE: [https://github.com/netty/netty/security/advisories/GHSA-xpw8-rcwv-8f8p.] It does not affect us, but we can clear it anyway.
Bug: Upgrade curator to 5.7.1
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 29/Feb/24 09:57

HBase still uses Curator 4.2.0, -because it's the last version to support ZK 3.4.-

Now that, with HBASE-28153, HBase uses a recent ZK, we can use the latest Curator.

Also, curator 4.2.0 has multiple indirect vulnerabilities as per https://mvnrepository.com/artifact/org.apache.curator/curator-client/4.2.0

Vulnerabilities from dependencies:
* CVE-2023-44981
* CVE-2023-2976
* CVE-2022-4065
* CVE-2020-8908
* CVE-2019-0201
Bug: Flush/Compaction journal logs are missing from 2.x 
Status: Open | Priority: Minor | Resolution: 
Created: 06/Feb/24 06:12

After refactoring of TaskMonitor from branch-1

[  public synchronized MonitoredTask createStatus(String description)|https://github.com/apache/hbase/blob/branch-2/hbase-server/src/main/java/org/apache/hadoop/hbase/monitoring/TaskMonitor.java#L87]

to branch-2/master

public MonitoredTask createStatus(String description){           [return createStatus(description, false);|https://github.com/apache/hbase/blob/branch-2/hbase-server/src/main/java/org/apache/hadoop/hbase/monitoring/TaskMonitor.java#L87] 

Flush journal logs are missing.
While flush, currently we do no set ignore monitor flag as true here 
[MonitoredTask status = TaskMonitor.get().createStatus("Flushing " + this);|https://github.com/apache/hbase/blob/branch-2/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java#L2459]
Bug: Add an option to count different types of Delete Markers in RowCounter
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 25/Jan/24 05:59

Add an option (count-delete-markers) to the [RowCounter|https://github.com/apache/hbase/blob/8a9ad0736621fa1b00b5ae90529ca6065f88c67f/hbase-mapreduce/src/main/java/org/apache/hadoop/hbase/mapreduce/RowCounter.java#L240C62-L240C75] tool to count the number of Delete Markers of all types, i.e. (DELETE, DELETE_COLUMN, DELETE_FAMILY,DELETE_FAMILY_VERSION)

We already have such a feature within our internal implementation of RowCounter and it's very useful.

Implementation Ideas:
1. If the option is passed, initialize the empty job counters for all 4 types of deletes.
2. Within mapper, increase the respective delete counts while processing each row.
Bug: New site configuration option "hfile.block.size"
Status: Open | Priority: Minor | Resolution: 
Created: 20/Mar/24 05:54
Affects Version/s: 2.5.0

Right now there is no config attached to the HFile block size by which we can override the default. The default is set to 64 KB in HConstants.DEFAULT_BLOCKSIZE . We need a global config property that would go on hbase-site.xm which can control this value.

Since the BLOCKSIZE is tracked at the column family level - we will need to respect the CFD value first. Also, configuration settings are also something that can be set in schema, at the column or table level, and will override the relevant values from the site file. Below is the precedence order we can use to get the final blocksize value :
{code:java}
ColumnFamilyDescriptor.BLOCKSIZE > schema level site configuration overrides > site configuration > HConstants.DEFAULT_BLOCKSIZE{code}
PS: There is one related config “hbase.mapreduce.hfileoutputformat.blocksize” however that is specific to map-reduce jobs.
Bug: Enable infra automation to add label on a Jira when a new PR is posted
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 23/Jan/24 09:55

https://cwiki.apache.org/confluence/display/INFRA/Git+-+.asf.yaml+features#Git.asf.yamlfeatures-Jiranotificationoptions

Currently we make use of the "link" feature. This does not send a notification to watchers, so I propose that we add the "comment" feature, so that a comment will also be sent, and watchers can find out about the availability of the PR.
Bug: Remove the reflection for ByteBufferPositionedReadable
Status: Open | Priority: Minor | Resolution: 
Created: 19/Mar/24 17:30

HBASE-21946 used reflection to access the ByteBufferPositionedReadable API that's only available in Hadoop 3.3.

Now that HBase branch-2.6 and above updated hadoop three dependency to 3.3, we can get rid of the reflection.