av9ash/GitBugs huggingface dataset:
Bug: Snapshots tab is always empty (not implemented) on Master web UI
Status: Resolved | Priority: Major | Resolution: Invalid
Created: 22/Nov/24 10:15
Affects Version/s: 4.0.0-alpha-1

While working on HBASE-28832 noticed that the Snapshots tab content on the Master web UI is always empty.

!image-2024-11-22-11-14-24-161.png|width=1307,height=664!

Actually the tab content div is completely empty in the .jamon file:
{code:java}
                    <div class="tab-pane" id="tab_userSnapshots">
                    </div> {code}
See: https://github.com/apache/hbase/blob/master/hbase-server/src/main/jamon/org/apache/hadoop/hbase/tmpl/master/MasterStatusTmpl.jamon#L286
Bug: Simplify & remove reflections in FanOutOneBlockAsyncDFSOutputSaslHelper
Status: Open | Priority: Major | Resolution: 
Created: 10/Dec/24 00:26
Affects Version/s: 3.0.0-beta-1

HBASE-23833 maintained compatibility for both Hadoop 3.3 and below, using reflection to access protobuf objects.

Now that HBase master branch moved up Hadoop version (3.4.1), we can remove the complex reflection hack to simplify the code. Make it less error prone.
Bug: Update logging references to org.apache.hadoop.ipc in docs and examples
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 06/Dec/24 09:15

That hasn't worked for a long time.

The correct  subsystem is:
_org.apache.hadoop.hbase.ipc_ or

_org.apache.hadoop.hbase.ipc.RpcServer_ .

and TRACE level is required.
Bug: Investigate integrating OpenAPI / Swagger to hbase-rest
Status: Resolved | Priority: Major | Resolution: Won't Do
Created: 13/Nov/24 14:19

Using OpenAPI / Swagger it would be possible to generate a schema file of HBase REST API.

In theory the generated schema file could be used as documentation / generating API clients.

Even Swagger UI could be used to have an interactive playground for the HBase REST API.

Check how much HBase could gain having this.
Bug: Duplicate dependency versions in assembly
Status: Resolved | Priority: Major | Resolution: Duplicate
Created: 28/Nov/24 12:02

When building master, I see the following duplicate dependencies in /lib in the assembly.
{noformat}
-rw-r--r-- 1 stoty stoty  193322 Jan 22  2020 checker-qual-2.5.2.jar
-rw-r--r-- 1 stoty stoty  204610 Jan 22  2020 checker-qual-3.1.0.jar
-rw-r--r-- 1 stoty stoty   36576 Jan 22  2020 jackson-module-jaxb-annotations-2.12.7.jar
-rw-r--r-- 1 stoty stoty   37123 Jan 22  2020 jackson-module-jaxb-annotations-2.17.2.jar
-rw-r--r-- 1 stoty stoty   44399 Jan 22  2020 jakarta.activation-api-1.2.1.jar
-rw-r--r-- 1 stoty stoty   46613 Jan 22  2020 jakarta.activation-api-1.2.2.jar
-rw-r--r-- 1 stoty stoty   25150 Jan 22  2020 jakarta.annotation-api-1.3.4.jar
-rw-r--r-- 1 stoty stoty   25058 Jan 22  2020 jakarta.annotation-api-1.3.5.jar
-rw-r--r-- 1 stoty stoty  115498 Jan 22  2020 jakarta.xml.bind-api-2.3.2.jar
-rw-r--r-- 1 stoty stoty  115638 Jan 22  2020 jakarta.xml.bind-api-2.3.3.jar
-rw-r--r-- 1 stoty stoty   56674 Jan 22  2020 javax.activation-api-1.2.0.jar
-rw-r--r-- 1 stoty stoty   26366 Jan 22  2020 javax.annotation-api-1.2.jar
-rw-r--r-- 1 stoty stoty  116120 Jan 22  2020 kerb-crypto-1.0.1.jar
-rw-r--r-- 1 stoty stoty  115065 Jan 22  2020 kerb-crypto-2.0.3.jar
-rw-r--r-- 1 stoty stoty   36708 Jan 22  2020 kerb-util-1.0.1.jar
-rw-r--r-- 1 stoty stoty   36361 Jan 22  2020 kerb-util-2.0.3.jar
-rw-r--r-- 1 stoty stoty   30674 Jan 22  2020 kerby-config-1.0.1.jar
-rw-r--r-- 1 stoty stoty   30190 Jan 22  2020 kerby-config-2.0.3.jar  {noformat}
Bug: bin/hbase-daemons.sh start rest does not work
Status: Open | Priority: Major | Resolution: 
Created: 05/Dec/24 09:56

The REST server cannot be started by the hbase-daemons.sh script:


{noformat}
2024-12-05T10:49:02,588 INFO  [main] RESTServer: ***** STARTING service 'RESTServer' *****
2024-12-05T10:49:02,592 INFO  [main] util.VersionInfo: HBase 4.0.0-alpha-1-SNAPSHOT
2024-12-05T10:49:02,592 INFO  [main] util.VersionInfo: Source code repository git://stoty-Precision-5570/home/stoty/workspaces/hbase/hbase revision=c556dde144612aa71524a011e01892316ca15d57
2024-12-05T10:49:02,592 INFO  [main] util.VersionInfo: Compiled by stoty on Wed Dec  4 03:33:22 PM CET 2024
2024-12-05T10:49:02,592 INFO  [main] util.VersionInfo: From source with checksum 560992c1bb047ee39799a052cd32c63379cb7622c8fa8ef46f6260c9ce65f50501eb8b041b6570791fd520f39648c75d2359a5344a04b85da65532baa0fa2d7e
2024-12-05T10:49:02,730 ERROR [main] RESTServer: Could not parse: 
org.apache.hbase.thirdparty.org.apache.commons.cli.UnrecognizedOptionException: Unrecognized option: -Dhbase.regionserver.port=16020
        at org.apache.hbase.thirdparty.org.apache.commons.cli.Parser.processOption(Parser.java:244) ~[hbase-shaded-miscellaneous-4.1.9.jar:4.1.9]
        at org.apache.hbase.thirdparty.org.apache.commons.cli.Parser.parse(Parser.java:176) ~[hbase-shaded-miscellaneous-4.1.9.jar:4.1.9]
        at org.apache.hbase.thirdparty.org.apache.commons.cli.Parser.parse(Parser.java:94) ~[hbase-shaded-miscellaneous-4.1.9.jar:4.1.9]
        at org.apache.hadoop.hbase.rest.RESTServer.parseCommandLine(RESTServer.java:181) ~[hbase-rest-4.0.0-alpha-1-SNAPSHOT.jar:4.0.0-alpha-1-SNAPSHOT]
        at org.apache.hadoop.hbase.rest.RESTServer.main(RESTServer.java:468) ~[hbase-rest-4.0.0-alpha-1-SNAPSHOT.jar:4.0.0-alpha-1-SNAPSHOT]
Thu Dec  5 10:55:16 AM CET 2024 Starting rest on stoty-Precision-5570
{noformat}
Bug: Cannot split hbase:quota table when quota enforcement is enabled
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 29/Nov/24 12:51
Affects Version/s: 2.5.0

When quotas are enabled, splitting the quota table fails due to the namespace region quotas system being partially initialized.

{noformat}
2024-11-28T14:11:38,672 ERROR [PEWorker-2 {}]
procedure2.ProcedureExecutor(1844): CODE-BUG: Uncaught runtime
exception: pid=7, state=RUNNABLE:SPLIT_TABLE_REGION_PRE_OPERATION,
hasLock=true; SplitTableRegionProcedure table=hbase:quota,
parent=3c1dbd551845ed2e8033b76570c6d8f6,
daughterA=a8f5e70728d93859d7c3d95aa5a0f63b,
daughterB=c71f49ad7e689a57742a9fe65b918d08
java.lang.NullPointerException: Cannot invoke
"java.util.concurrent.atomic.AtomicInteger.addAndGet(int)" because the
return value of "java.util.Map.get(Object)" is null
at org.apache.hadoop.hbase.namespace.NamespaceTableAndRegionInfo.incRegionCountForTable(NamespaceTableAndRegionInfo.java:101)
~[classes/:?]
at org.apache.hadoop.hbase.namespace.NamespaceStateManager.checkAndUpdateNamespaceRegionCount(NamespaceStateManager.java:95)
~[classes/:?]
at org.apache.hadoop.hbase.namespace.NamespaceAuditor.checkQuotaToSplitRegion(NamespaceAuditor.java:116)
~[classes/:?]
at org.apache.hadoop.hbase.quotas.MasterQuotaManager.onRegionSplit(MasterQuotaManager.java:544)
~[classes/:?]
at org.apache.hadoop.hbase.master.assignment.SplitTableRegionProcedure.preSplitRegion(SplitTableRegionProcedure.java:607)
~[classes/:?]
at org.apache.hadoop.hbase.master.assignment.SplitTableRegionProcedure.executeFromState(SplitTableRegionProcedure.java:298)
~[classes/:?]
at org.apache.hadoop.hbase.master.assignment.SplitTableRegionProcedure.executeFromState(SplitTableRegionProcedure.java:98)
~[classes/:?]
at org.apache.hadoop.hbase.procedure2.StateMachineProcedure.execute(StateMachineProcedure.java:188)
~[classes/:?]
at org.apache.hadoop.hbase.procedure2.Procedure.doExecute(Procedure.java:941)
~[classes/:?]
at org.apache.hadoop.hbase.procedure2.ProcedureExecutor.execProcedure(ProcedureExecutor.java:1825)
~[classes/:?]
at org.apache.hadoop.hbase.procedure2.ProcedureExecutor.executeProcedure(ProcedureExecutor.java:1503)
~[classes/:?]
at org.apache.hadoop.hbase.procedure2.ProcedureExecutor$WorkerThread.runProcedure(ProcedureExecutor.java:2154)
~[classes/:?]
at org.apache.hadoop.hbase.trace.TraceUtil.trace(TraceUtil.java:216)
~[classes/:?]
at org.apache.hadoop.hbase.procedure2.ProcedureExecutor$WorkerThread.run(ProcedureExecutor.java:2181)
~[classes/:?]
{noformat}

See discussion on the dev list, https://lists.apache.org/thread/gdnjb1ys8m93lowykdrh4m7o55mgw3vo
Bug: Clear all meta caches of the server on which hardware failure related exceptions occurred
Status: Patch Available | Priority: Major | Resolution: 
Created: 28/Oct/24 03:23
Affects Version/s: 2.4.18

CallTimeoutException and ConnectException might be caused by a network or hardware issue of that server. We might not be able to connect to that server for a while. So we have to clear all meta caches of the server on which hardware failure related exceptions occurred. If we don't clear the caches, we might get the same exceptions as many times as the number of location caches of that server.
 
https://issues.apache.org/jira/browse/HBASE-7590
https://issues.apache.org/jira/browse/HBASE-22261
We already have ClusterStatusPublisher/Listener feature. But it is not possible to use this feature in some infrastructure environments like me.
Bug: SLF4j logging backend incorrectly picked up from Hadoop when external Hadoop is specified
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 27/Nov/24 12:20
Affects Version/s: 2.5.10

When I set  HADOOP_CLASSPATH:
{noformat}
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/home/stoty/x/hadoop-3.4.1/share/hadoop/common/lib/slf4j-reload4j-1.7.36.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/home/stoty/workspaces/hbase/hbase/hbase-assembly/target/hbase-2.5.11-SNAPSHOT-client/lib/client-facing-thirdparty/log4j-slf4j-impl-2.17.2.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [org.slf4j.impl.Reload4jLoggerFactory]
{noformat}
HBase should always pick its own log4j2 backend.
Bug: The region assignment retry logic in unconstrained and may cause workload amplification
Status: Open | Priority: Major | Resolution: 
Created: 30/Nov/24 04:59
Affects Version/s: 2.6.0

We found a potential feedback loop in the region assignment process that may overload the RegionServer (RS).

The `AssigmentManager.processAssignmentPlans()` will retry the assignment when any HBaseIOException happens. For example, `FavoerableNodeAssignmentHelper.canPlaceFavoredNodes` may throw an HIOE when the nodes available are less than three. The HIOE will be caught by the catch block here:
{code:java}
  private void processAssignmentPlans(final HashMap<RegionInfo, RegionStateNode> regions,
    final HashMap<RegionInfo, ServerName> retainMap, final List<RegionInfo> hris,
    final List<ServerName> servers) {
    boolean isTraceEnabled = LOG.isTraceEnabled();
    if (isTraceEnabled) {
      LOG.trace("Available servers count=" + servers.size() + ": " + servers);
    }    final LoadBalancer balancer = getBalancer();
    // ask the balancer where to place regions
    if (retainMap != null && !retainMap.isEmpty()) {
      if (isTraceEnabled) {
        LOG.trace("retain assign regions=" + retainMap);
      }
      try {
        acceptPlan(regions, balancer.retainAssignment(retainMap, servers));
      } catch (HBaseIOException e) {
        LOG.warn("unable to retain assignment", e);
        addToPendingAssignment(regions, retainMap.keySet());
      }
    } {code}
The assignment is simply retried and is not bounded.

This can cause problems when the assignment fails because the RS is overloaded. More retries in the region assignment can make the overloading worse.
Bug: Remove lib/jdk11 directory in 3.0+
Status: Resolved | Priority: Major | Resolution: Duplicate
Created: 28/Nov/24 09:05
Affects Version/s: 3.0.0-beta-2

As 3.0+ requires JDK17+, there is no longer a point in handling the libraries that were removed from JDK11 specially.

I propose removing the jdk11 directory, and treating those libraries like the rest of the dependencies. The special code handling it could also be removed from the script(s).

WDYT [~zhangduo] [~ndimiduk] [~nihaljain] ?
Bug: Table Regions Total Locality value on the UI shows 1.0 even though some of the regions locality value is zero
Status: Open | Priority: Major | Resolution: 
Created: 23/Nov/24 15:50

Table Regions Total Locality value on the UI shows 1.0 even though some of the regions locality value is zero. This is due to the rounding of happening inside the String.format() function. 

I have a table with 200 regions and 1 of the regions locality is zero, the overall locality calculated value is ~0.99524385, but the String.format function rounded of this value to 1.0.

If some of the table regions localtiy is zero then we should not show the total Locality of the table as 1.0 as this can be misleading  to the user.
Bug: Meta replication is inconsistent after startup when reusing hbase storage location
Status: Open | Priority: Major | Resolution: 
Created: 06/Nov/24 15:01

Meta replication is inconsistent after startup when reusing HBase storage location for example the new cluster is created with the same S3 storage location that a previous one had. 
USE_META_REPLICAS is set to true
META_REPLICAS_NUM is set to 3
For both
hbck output:
{noformat}
ERROR: hbase:meta, replicaId 1 is not found on any region.
ERROR: hbase:meta, replicaId 2 is not found on any region.
ERROR: hbase:meta table is not consistent. Run HBCK with proper fix options to fix hbase:meta inconsistency. Exiting...
Summary:
3 inconsistencies detected.
Status: INCONSISTENT{noformat}
Bug: Enhance Remaining Backup Commands to Support Continuous Backup and Point-in-Time Recovery (PITR)
Status: Open | Priority: Major | Resolution: 
Created: 21/Nov/24 12:48
Affects Version/s: 2.6.0

Investigate whether any of the following remaining commands need modification to support continuous backup. If necessary, make the required changes:
 * Merge
 * Describe
 * Progress
 * History
 * Repair
 * Help
Bug: Ensure the Existing "Delete" Backup Command Functions Properly with Continuous Backup Enablement
Status: Open | Priority: Major | Resolution: 
Created: 21/Nov/24 12:43
Affects Version/s: 2.6.0

Ensure that the current "Delete" backup command continues to work as expected. Additionally, the command should:
 * Clean up the replication peer.
 * Provide an option to purge all collected data from the storage.
Bug: Add a "Cleanup" Command to Free Up Storage Beyond a Specified Time Period
Status: Open | Priority: Major | Resolution: 
Created: 21/Nov/24 12:40
Affects Version/s: 2.6.0

Implement a "cleanup" command to allow users to free up storage by removing data older than a specified time period. This should include:
 * Full backup cleanup
 * WAL cleanup
 * HFile cleanup
Bug: Adding support for continuous Backup and Point-in-Time Recovery
Status: Open | Priority: Major | Resolution: 
Created: 04/Nov/24 22:46
Affects Version/s: 2.6.0

Current solutions like replication and snapshots offer data redundancy but have limitations that prevent effective point-in-time recovery in cases of data corruption or accidental changes. Replication requires maintaining a live cluster that mirrors the original, which incurs substantial costs to keep both clusters operational. Snapshots, on the other hand, do not support point-in-time recovery, leading to potential data loss between snapshots. Incremental snapshots improve this situation but still do not provide full protection, as they only capture data at specific intervals.

Limitations of the Current Incremental Backup Solution

The current incremental backup solution in HBase has several critical limitations that highlight the need for continuous backup and PITR:

	•	Risk of Data Loss: Since incremental backups are created in batches rather than continuously, any changes made since the last backup are at risk of being lost if data corruption or deletion occurs before the next scheduled backup.
	•	Restore Point Limitations: Users can only restore data to specific backup timestamps rather than any exact moment in time, restricting flexibility and the ability to revert to the most recent stable state before an issue.
	•	WAL Management Challenges: Write-Ahead Logs on the source cluster cannot be archived until the backup process completes, making WAL management complex and storage-intensive on the source cluster.
	•	Complex Backup Tracking: Managing backup IDs, job history, and logs is currently challenging, requiring substantial manual tracking and oversight to ensure consistency.
	•	Dependency on YARN: The incremental backup process relies on a YARN cluster to move WALs, adding both resource dependency and complexity to the backup workflow.
Bug: Fix UT flakeyness in TestBucketCache.testBlockAdditionWaitWhenCache and TestVerifyBucketCacheFile.testRetrieveFromFile
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 13/Nov/24 11:39
Affects Version/s: 2.5.10

Noticed these two tests failing intermittently on some of the pre-commit runs. 

1) TestBucketCache.testBlockAdditionWaitWhenCache: The test calls 
BucketCache.cacheBlock() passing true to the waitWhenCache parameter, assuming the cache call will wait for a success cache, however this is only true if the BucketCache.QUEUE_ADDITION_WAIT_TIME property is also defined, so I believe this may be causing the intermittent failures when the pre-commit runs on slower vms.
 
2) TestVerifyBucketCacheFile.testRetrieveFromFile: One of the checks performed by this test is to delete the bucket cache file, shutdown the current BucketCache instance, then create a new BucketCache instance that would load the persistent file but should fail to recover the cache, as the cache file has been deleted. The way this recover works, internally, is async. We first read the contents of the persistent file, which includes the last serialized backingMap and a checksum of the cache file at that time. It then compares this recovered checksum against the current cache file checksum. If this verification fails, it starts a background thread to traverse all backingMap entries and check if those entries are still available in the cache. At this point, the test is ready to check the BucketCache allocator size, expecting it to be 0, but if the background verification has not finished yet, this assert will fail.
Bug: Support client access to HBase servers using IP in IPV6 env
Status: Open | Priority: Major | Resolution: 
Created: 09/Nov/24 13:37
Affects Version/s: 3.0.0-alpha-4

Using IPV6 address failed to create the WAL path.

IPV6 address contains ":", eg: [0:0:0:0:0:0:0:1]

WAL path creation will fail, because FS will not support to create path with ":".

so for use IP is true and the env is ipv6
 # Encode for wal path creation with IPV6 address
 # Decode the IPV6 address, if RS servernames are prepared from the WAL path.

{noformat}
 2024-11-18 10:55:43,931 | ERROR | master/<HOSTNAME>:16000:becomeActiveMaster | ***** ABORTING master 0:0:0:0:0:0:0:1,16000,1731910552237: Unhandled exception. Starting shutdown. ***** | org.slf4j.helpers.MarkerIgnoringBase.error(MarkerIgnoringBase.java:159)
java.lang.IllegalArgumentException: Pathname /hbase/MasterData/WALs/0:0:0:0:0:0:0:1,16000,1731910552237 from hdfs://hacluster/hbase/MasterData/WALs/0:0:0:0:0:0:0:1,16000,1731910552237 is not a valid DFS filename.
        at org.apache.hadoop.hdfs.DistributedFileSystem.getPathName(DistributedFileSystem.java:272)
        at org.apache.hadoop.hdfs.DistributedFileSystem$31.doCall(DistributedFileSystem.java:1849)
        at org.apache.hadoop.hdfs.DistributedFileSystem$31.doCall(DistributedFileSystem.java:1846)
        at org.apache.hadoop.fs.FileSystemLinkResolver.resolve(FileSystemLinkResolver.java:81)
        at org.apache.hadoop.hdfs.DistributedFileSystem.getFileStatus(DistributedFileSystem.java:1861)
        at org.apache.hadoop.fs.FileSystem.exists(FileSystem.java:1811)
        at org.apache.hadoop.hbase.master.region.MasterRegion.createWAL(MasterRegion.java:192)
        at org.apache.hadoop.hbase.master.region.MasterRegion.open(MasterRegion.java:263)
        at org.apache.hadoop.hbase.master.region.MasterRegion.create(MasterRegion.java:344)
        at org.apache.hadoop.hbase.master.region.MasterRegionFactory.create(MasterRegionFactory.java:104)
        at org.apache.hadoop.hbase.master.HMaster.finishActiveMasterInitialization(HMaster.java:892)
        at org.apache.hadoop.hbase.master.HMaster.startActiveMasterManager(HMaster.java:2485)
        at org.apache.hadoop.hbase.master.HMaster.lambda$run$0(HMaster.java:558)
        at java.lang.Thread.run(Thread.java:750){noformat}
IPV6 address contains colon( : ) which is not a valid name in HDFS.
Bug: Updating Quota Factors is too expensive
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 06/Nov/24 16:53
Affects Version/s: 2.6.1

My company is running Quotas across a few hundred clusters of varied size. One cluster has hundreds of servers and tens of thousands of regions. We noticed that the HMaster was quite busy for this cluster, and after some investigation we realized that RegionServers were hammering the HMaster's ClusterMetrics endpoint to facilitate the refreshing of table machine quota factors.

There are a few things that we could do here — in a perfect world, I think the RegionServers would have a better P2P communication of region states, and whatever else is, necessary to derive new quota factors. Relying solely on the HMaster for this coordination creates a tricky bottleneck for the horizontal scalability of clusters.

That said, I think that a simpler and preferable initial step would be to make our code a bit more cost conscious. At my company, for example, we don't even define any table-scoped quotas. Without any table scoped quotas in the cache, our cache could be much more thoughtful about the work that it chooses to do on each refresh. So I'm proposing that we check [the size of the tableQuotaCache keyset|https://github.com/apache/hbase/blob/db3ba44a4c692d26e70b6030fc519e92fd79f638/hbase-server/src/main/java/org/apache/hadoop/hbase/quotas/QuotaCache.java#L418] earlier, and use this inference to determine what ClusterMetrics we bother to fetch.
Bug: Improve lease renew for FanOutOneBlockAsyncDFSOutput
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 04/Nov/24 11:15

When working with hadoop 3.4.x, we saw this in the stdout file

{noformat}
Exception in thread "LeaseRenewer:zhangduo@home" java.lang.NullPointerException: Cannot invoke "org.apache.hadoop.hdfs.DFSOutputStream.getNamespace()" because "outputStream" is null
        at org.apache.hadoop.hdfs.DFSClient.getNamespaces(DFSClient.java:596)
        at org.apache.hadoop.hdfs.DFSClient.renewLease(DFSClient.java:618)
        at org.apache.hadoop.hdfs.client.impl.LeaseRenewer.renew(LeaseRenewer.java:425)
        at org.apache.hadoop.hdfs.client.impl.LeaseRenewer.run(LeaseRenewer.java:445)
        at org.apache.hadoop.hdfs.client.impl.LeaseRenewer.access$800(LeaseRenewer.java:77)
        at org.apache.hadoop.hdfs.client.impl.LeaseRenewer$1.run(LeaseRenewer.java:336)
        at java.base/java.lang.Thread.run(Thread.java:840)
{noformat}

This is because in  newer DFSClient implementation, we need to pass namespace when renewer lease so we can not just pass null as DFSOutputStream when calling DFSClient.beginFileLease. We should find a way to deal with it.
Bug: Make the approach in HBASE-28955 can work together with hadoop 2.x
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 07/Nov/24 06:54

The solution before HBASE-28955 can work with hadoop 2.x but after applying the changes in HBASE-28955, we can work with hadoop 3.4.x but we can not compile with hadoop 2.x then.

We should find a way to support hadoop 2.x so we can also port the changes to branch-2.x as well.
Bug: Update dev-support/hbase_docker Dockerfiles to use JDK17
Status: Open | Priority: Major | Resolution: 
Created: 12/Nov/24 23:50
Affects Version/s: 4.0.0-alpha-1

HBase master branch requires JDK17, but the docker files under dev-support/hbase_docker install only JDK8. Time to update to JDK17.