av9ash/GitBugs huggingface dataset:
Bug: Fix Wrong FileSystem when running `filesystem` on non-HDFS storage
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 26/May/21 03:29
Affects Version/s: 1.0.0

recently we found a bug that when running {{hbck filesystem -f}} on a non-HDFS and caused {{Wrong FS}} error and cannot move forward.

this change fix this problem and use {{FSUtils.getCurrentFileSystem}} to respect the root directory of what we set with {{hbase.rootdir}} in stead of just using {{fs.defaultFS}}




e.g. this is one of the captured ERROR message


 {code}
Exception in thread "main" java.lang.IllegalArgumentException: Wrong FS: s3://xyz/data/default/abc, expected: hdfs://xyz/
        at org.apache.hadoop.fs.FileSystem.checkPath(FileSystem.java:737)
        at org.apache.hadoop.hdfs.DistributedFileSystem.getPathName(DistributedFileSystem.java:233)
        at org.apache.hadoop.hdfs.DistributedFileSystem.listStatusInternal(DistributedFileSystem.java:1045)
        at org.apache.hadoop.hdfs.DistributedFileSystem.access$1000(DistributedFileSystem.java:131)
        at org.apache.hadoop.hdfs.DistributedFileSystem$24.doCall(DistributedFileSystem.java:1112)
        at org.apache.hadoop.hdfs.DistributedFileSystem$24.doCall(DistributedFileSystem.java:1109)
        at org.apache.hadoop.fs.FileSystemLinkResolver.resolve(FileSystemLinkResolver.java:81)
        at org.apache.hadoop.hdfs.DistributedFileSystem.listStatus(DistributedFileSystem.java:1119)
        at org.apache.hadoop.hbase.util.FSUtils.listStatusWithStatusFilter(FSUtils.java:1530)
        at org.apache.hbase.hbck1.HFileCorruptionChecker.checkTableDir(HFileCorruptionChecker.java:320)
        at org.apache.hbase.hbck1.HFileCorruptionChecker.checkTables(HFileCorruptionChecker.java:431)
        at org.apache.hbase.FileSystemFsck.fsck(FileSystemFsck.java:87)
        at org.apache.hbase.HBCK2.doCommandLine(HBCK2.java:721)
        at org.apache.hbase.HBCK2.run(HBCK2.java:631)
        at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:76)
        at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:90)
        at org.apache.hbase.HBCK2.main(HBCK2.java:865)

 {code}
Bug: HFilePrettyPrinter tool can not print the last LEAF_INDEX block or BLOOM_CHUNK.
Status: Open | Priority: Minor | Resolution: 
Created: 19/Jun/21 03:23
Affects Version/s: 2.1.0

when i use pretty printer tool to print the headers of block, i can not get the last LEAF_INDEX block and BLOOM_CHUNK. the last info of the tools is blow:
Bug: Reference class incorrectly parses the protobuf magic marker
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 06/May/21 12:10
Affects Version/s: 2.4.1

The Reference class incorrectly parses the protobuf magic marker.

It uses:
{code:java}
// DataInputStream.read(byte[lengthOfPNMagic]){code}
but this call does not guarantee to read all the bytes of the marker.
 The fix is the same as the one for https://issues.apache.org/jira/browse/HBASE-25674
Bug: Expose the NORMALIZARION_ENABLED table descriptor through a property in hbase-site
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 09/Jun/21 07:56

Today if we want to enable region normalizer on a table we have to add the table descriptor "{color:#6a8759}NORMALIZATION_ENABLED{color}" to the table. If we have a lot of tables and we want normalizer to be enabled by default for each table unless disabled explicitly for a table we can't achieve it 

[https://github.com/apache/hbase/blob/master/hbase-client/src/main/java/org/apache/hadoop/hbase/client/TableDescriptorBuilder.java#L164]

 

Intention here is to set it using a property in hbase-site
Bug: Get operations readRows metrics becomes zero after HBASE-25677
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 18/Jun/21 08:37

After HBASE-25677, Server+table counters on each scan are extracted from #nextRaw to rsServices scan. In this case, the get operation will not count the read rows. So that the readRows metrics becomes zero. Should add counter in metricsUpdateForGet.
Bug: Fix hbase-operator-tools build with HBase 2.4.4
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 30/Jun/21 19:14
Affects Version/s: hbase-operator-tools-1.2.0

I tried building hbase-operator-tools with HBase 2.4.4 and encountered a number of issues. Opening this for the fix.



{noformat}
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (default-compile) on project hbase-hbck2: Compilation failure: Compilation failure:
[ERROR] /Users/zyork/workspace/apache/hbase-operator-tools/hbase-hbck2/src/main/java/org/apache/hbase/HBCKAbstractFileStatusFilter.java:[20,39] package edu.umd.cs.findbugs.annotations does not exist
[ERROR] /Users/zyork/workspace/apache/hbase-operator-tools/hbase-hbck2/src/main/java/org/apache/hbase/HBCKAbstractFileStatusFilter.java:[52,46] cannot find symbol
[ERROR]   symbol:   class CheckForNull
[ERROR]   location: class org.apache.hbase.HBCKAbstractFileStatusFilter
[ERROR] /Users/zyork/workspace/apache/hbase-operator-tools/hbase-hbck2/src/main/java/org/apache/hbase/HBCKAbstractFileStatusFilter.java:[64,44] cannot find symbol
[ERROR]   symbol:   class CheckForNull
[ERROR]   location: class org.apache.hbase.HBCKAbstractFileStatusFilter
[ERROR] /Users/zyork/workspace/apache/hbase-operator-tools/hbase-hbck2/src/main/java/org/apache/hbase/HBCKAbstractFileStatusFilter.java:[68,49] cannot find symbol
[ERROR]   symbol:   class CheckForNull
[ERROR]   location: class org.apache.hbase.HBCKAbstractFileStatusFilter
[ERROR] /Users/zyork/workspace/apache/hbase-operator-tools/hbase-hbck2/src/main/java/org/apache/hbase/HBCKFsUtils.java:[367,39] cannot find symbol
[ERROR]   symbol:   class CheckForNull
[ERROR]   location: class org.apache.hbase.HBCKFsUtils.FamilyDirFilter
[ERROR] /Users/zyork/workspace/apache/hbase-operator-tools/hbase-hbck2/src/main/java/org/apache/hbase/HBCKFsUtils.java:[402,39] cannot find symbol
[ERROR]   symbol:   class CheckForNull
[ERROR]   location: class org.apache.hbase.HBCKFsUtils.RegionDirFilter
[ERROR] -> [Help 1]
{noformat}

The Threads change is masked by these changes, but the method is clearly removed in HBASE-24750
`
Bug: Redundant null check in the compareTo function 
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 28/Jun/21 23:27

Remove a redundant null check in the compareTo function 

{code:java}
if (!(source instanceof MetricsRegionSourceImpl)) {
      return -1;
    }

    MetricsRegionSourceImpl impl = (MetricsRegionSourceImpl) source;
    if (impl == null) {
      return -1;
    }

{code}
Bug: Improve logging and dequeue logic in DelayQueue
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 17/Jun/21 17:05
Affects Version/s: 2.3.5

In Remote Procedure dispatcher, before submitting (sub)Procedure to Thread pool, we enqueue it as DelayedWithTimeout object on DelayQueue. 

TimeoutExecutorThread keeps dequeuing elements from this DelayQueue and submit the Procedure to the threadpool. The expiration of DelayedWithTimeout is determined by getDelay(TimeUnit):
{code:java}
@Override
public long getDelay(final TimeUnit unit) {
  return DelayedUtil.getRemainingTime(unit, getTimeout());
}
{code}
{code:java}
  /**
   * @return Time remaining as milliseconds.
   */
  public static long getRemainingTime(final TimeUnit resultUnit, final long timeout) {
    final long currentTime = EnvironmentEdgeManager.currentTime();
    if (currentTime >= timeout) {
      return 0;
    }
    return resultUnit.convert(timeout - currentTime, TimeUnit.MILLISECONDS);
  }
{code}
Hence, in order for the elements to get dequeued on time, it is necessary that EnvironmentEdgeManager.currentTime() returns the current time in millis.

As part of unit test, if we use our own custom EnvironmentEdge and inject it using EnvironmentEdgeManager.injectEdge before creating any tables, it is possible that we continue returning same value (based on custom impl) with EnvironmentEdgeManager.currentTime(). If that is the case, getRemainingTime as mentioned above, will never return 0 and hence, the procedure wrapped in DelayedWithTimeout might never be dequeued from DelayQueue because it's delay will not expire.

As of today, our system goes in hanging state while waiting for table regions to be available (as mentioned above, DelayedWithTimeout object never gets dequeued from DelayQueue).

Thread dump might show something like this consistently:
{code:java}
"ProcedureDispatcherTimeoutThread" #319 daemon prio=5 os_prio=31 tid=0x00007fcaf0cae800 nid=0x21d03 waiting on condition [0x0000700019293000]
   java.lang.Thread.State: TIMED_WAITING (parking)
  at sun.misc.Unsafe.park(Native Method)
  - parking to wait for  <0x00000007225a0090> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
  at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
  at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
  at java.util.concurrent.DelayQueue.take(DelayQueue.java:223)
  at org.apache.hadoop.hbase.procedure2.util.DelayedUtil.takeWithoutInterrupt(DelayedUtil.java:82)
  at org.apache.hadoop.hbase.procedure2.RemoteProcedureDispatcher$TimeoutExecutorThread.run(RemoteProcedureDispatcher.java:314)
   Locked ownable synchronizers:
  - None
{code}
Although running into situation like this is not likely possible unless custom EnvironmentEdge is used as mentioned above, we should improve our dequeue logic as well as log important message to show where we are stuck.
Bug: Optimize the display of ZK dump in the master web UI
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 13/Jun/21 07:13
Affects Version/s: 2.3.5

Optimize the display of ZK dump in the master web UI.
h3. *Before:*

_*hbase:meta with 1 replica:*_

!1-replica-before.jpg|width=667,height=215!

_*hbase:meta with 3 replica:*_

!3-replica-before.jpg|width=658,height=187!
h3. *After:*

_*hbase:meta with 1 replica:*_

  !1-replica-after.jpg|width=648,height=229!

_*hbase:meta with 3 replica:*_

!3-replica-after.jpg|width=656,height=254!
Bug: NettyRpcServerRequestDecoder.exceptionCaught log e instead of e.getCause
Status: Resolved | Priority: Minor | Resolution: Won't Fix
Created: 08/Jun/21 10:53

After this change, we can get exception, otherwise null

2021-06-08T18:50:38,235 TRACE [NettyRpcServer-4-2] ipc.NettyRpcServerRequestDecoder(76): Connection /127.0.1.1:46443; caught unexpected downstream exception.2021-06-08T18:50:38,235 DEBUG [NettyRpcServer-4-2] ipc.NettyRpcServerRequestDecoder(76): Connection /127.0.1.1:46443; caught unexpected downstream exception.org.apache.hadoop.hbase.ipc.UnknownServiceException: CompactionService at org.apache.hadoop.hbase.ipc.ServerRpcConnection.processConnectionHeader(ServerRpcConnection.java:498) ~[classes/:?] at org.apache.hadoop.hbase.ipc.ServerRpcConnection.processOneRpc(ServerRpcConnection.java:450) ~[classes/:?] at org.apache.hadoop.hbase.ipc.NettyServerRpcConnection.process(NettyServerRpcConnection.java:89) ~[classes/:?] at org.apache.hadoop.hbase.ipc.NettyServerRpcConnection.process(NettyServerRpcConnection.java:73) ~[classes/:?] at org.apache.hadoop.hbase.ipc.NettyServerRpcConnection.process(NettyServerRpcConnection.java:68) ~[classes/:?] at org.apache.hadoop.hbase.ipc.NettyRpcServerRequestDecoder.channelRead(NettyRpcServerRequestDecoder.java:62) ~[classes/:?] at org.apache.hbase.thirdparty.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
Bug: Stateless scanner endpoint documentation missing
Status: Open | Priority: Minor | Resolution: 
Created: 07/Jun/21 05:03
Affects Version/s: 2.4.3

Hbase older versions(For example: 1.2) has [documentation for stateless scanner|https://hbase.apache.org/1.2/apidocs/org/apache/hadoop/hbase/rest/package-summary.html#operation_stateless_scanner] endpoints. But there is no mention of it in [recent documentation|[http://hbase.apache.org/book.html#_rest]|http://hbase.apache.org/book.html#_rest].]
Bug: Improve Logging Statement Formatting
Status: Open | Priority: Minor | Resolution: 
Created: 28/May/21 13:31

I reviewed most of the TRACE/DEBUG log statements and wanted to clean up the first tier issues:

 
 * Use logging anchors {{{}}} where previously was concatenating (without logging guard)
 * Remove String.format and use logging anchors {{{}}}
 * Remove logging guards around statements which use anchors (kind of defeats the purpose of anchors)
 * Remove logging guards around log statements which have no parameters (not concatenation)
 * Remove explicit calls to toString() that defeat the purpose of anchors
 * Remove Objects.toString() - logging framework will handle {{null}} values
 * Remove StringUtils ExceptionStackTrace logging - logging framework will handle pretty-print of Exception messages and stack traces
 * Remove logging guards around INFO messages.  They will just about always be printed in production systems, no need to try to protect them from happening

The goal here is, maybe a tiny bump in performance, but to reduce the size of the code and to make logging statement more clear to developers.
Bug: Fix uses of System.currentTimeMillis (should be EnvironmentEdgeManager.currentTime)
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 25/May/21 00:05

We introduced EnvironmentEdgeManager a long time ago as a way to inject alternate clocks (gettimeofday() aka System.currentTimeMillis()) for unit tests. In order for this to be effective, all callers that would otherwise use System.currentTimeMillis() must call EnvironmentEdgeManager.currentTime() instead, except obviously the implementors of EnvironmentEdge.

It's common for contributors to be unaware of this practice and reviewers might not catch it.

It will be much more important to have EnvironmentEdgeManager in use where expected once we have EnvironmentEdge also providing a monotonic clock source. (See parent.)

On another subtask I will introduce a build enforcer that bans System.currentTimeMillis() except where annotated to allow it.
Bug: Fix TestClusterPortAssignment.testClusterPortAssignment test and re-enable it.
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 24/May/21 23:48

This test assigned with random unused ports for master and region server ports and start a cluster, however it can fail as the previously unsigned port might be taken by other application at the moment when cluster start to bind the ports.

Server has an option to allow auto assign an port if the port is unavailable. This option needs to be disabled in this test in order to test explicit port assignment.

The exception for the failure of starting server needs to change to IOException and there is a need to set a retry count instead of infinite retry.

Related ticket: https://issues.apache.org/jira/browse/HBASE-24342
Bug: Fix the log messages by not stringifying the exceptions in log
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 26/May/21 16:48
Affects Version/s: 2.4.4

There are few places where we stringify the exceptions and log, instead we should just pass them as a parameter to see the stack trace in good format. 

For example: https://github.com/apache/hbase/blob/master/hbase-server/src/main/java/org/apache/hadoop/hbase/replication/regionserver/ReplicationSourceWALReader.java#L175
Bug: Deprecate/Rename config `hbase.normalizer.min.region.count` to `hbase.normalizer.merge.min.region.count`
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 07/Apr/21 20:22
Affects Version/s: 2.5.0

After HBASE-24416, {{hbase.normalizer.min.region.count}} only applies to merge plans. Let's deprecate/rename the configuration key so that it is clear in what context it applies, and so that it matches the configuration structure of related keys.
Bug: Log trace raw exception, instead of cause message in NettyRpcServerRequestDecoder
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 27/May/21 14:39
Affects Version/s: 2.2.7

In *NettyRpcServerRequestDecoder,* override of *exceptionCaught* method tries to log the exception cause message, however this not always will have a content, causing debugging of connection failure issues harder to troubleshoot. We should simply log trace the observed *Throwable* reference itself:

 
{noformat}
diff --git a/hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/NettyRpcServerRequestDecoder.java b/hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/NettyRpcServerRequestDecoder.java
index 1e844bb02cb..40f59ad1259 100644
--- a/hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/NettyRpcServerRequestDecoder.java
+++ b/hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/NettyRpcServerRequestDecoder.java
@@ -74,7 +74,7 @@ class NettyRpcServerRequestDecoder extends ChannelInboundHandlerAdapter {
   public void exceptionCaught(ChannelHandlerContext ctx, Throwable e) {
     allChannels.remove(ctx.channel());
     NettyRpcServer.LOG.trace("Connection {}; caught unexpected downstream exception.",
-        ctx.channel().remoteAddress(), e.getCause());
+        ctx.channel().remoteAddress(), e);
     ctx.channel().close();
   }
 }
 {noformat}
Bug: RESTServer should implement Hadoop's Tool interface
Status: Open | Priority: Minor | Resolution: 
Created: 07/May/21 20:16

The class that provides the main entry point for the REST gateway appears to be entirely hand-constructed. Instead, this should probably use the common {{Tool}} support provided by Hadoop, so that it can do things like parse command line configuration parameters. For example, it could extend from {{AbstractHBaseTool}}.
Bug: Batch version of checkAndMutate on AsyncTable always returns false
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 20/Apr/21 23:11
Affects Version/s: 2.4.1

Batch version of CheckAndMutate always returns false whereas non-batch version works fine. 

The code is like: 

 
{code:java}
AysncTable<?> table = connection.getTable(tableName, executorService);
...
// add r1
table.put(Arrays.asList(
 new Put(Bytes.toBytes("r1")).addColumn(COL_FAMILY, Bytes.toBytes("q1"), Bytes.toBytes("v1"))));
CheckAndMutate checkAndMutate1 = CheckAndMutate.newBuilder(Bytes.toBytes("r1"))
 .ifNotExists(COL_FAMILY, Bytes.toBytes("q1"))
 .build(new Put(Bytes.toBytes("r1")).addColumn(COL_FAMILY, Bytes.toBytes("q1"), Bytes.toBytes("v1")));
CheckAndMutate checkAndMutate2 = CheckAndMutate.newBuilder(Bytes.toBytes("r2"))
 .ifNotExists(COL_FAMILY, Bytes.toBytes("q2"))
 .build(new Put(Bytes.toBytes("r2")).addColumn(COL_FAMILY, Bytes.toBytes("q2"), Bytes.toBytes("v2")));

{code}
 

With batch version of checkAndMutate
{code:java}
List<CompletableFuture<CheckAndMutateResult>> results =
    table.checkAndMutate(Arrays.asList(checkAndMutate1, checkAndMutate2));
System.out.println("first: " + results.get(0).join().isSuccess());  // false
System.out.println("second: " + results.get(1).join().isSuccess()); //false!
{code}
 

 

Even it returned false, the r1 was written to the table. (timestamp was updated) 

 

With non-batch version of checkAndMutate

 
{code:java}
CompletableFuture<CheckAndMutateResult> result1 = table.checkAndMutate(checkAndMutate1);
 CompletableFuture<CheckAndMutateResult> result2 = table.checkAndMutate(checkAndMutate2);
System.out.println("first: " + result1.join().isSuccess()); // false 
System.out.println("second: " + result2.join().isSuccess()); // true as expected
{code}
 

As expected r1 wasn't written to the table.
Bug: Backport 'HBASE-25825 RSGroupBasedLoadBalancer.onConfigurationChange should chain the request to internal balancer' to branch-1
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 04/May/21 20:43

In branch-1, [RSGroupBasedLoadBalancer#onConfigurationChange|https://github.com/apache/hbase/blob/branch-1/hbase-rsgroup/src/main/java/org/apache/hadoop/hbase/rsgroup/RSGroupBasedLoadBalancer.java#L452] doesn't do anything – it should call the internal balancer's onConfigurationChange().
Bug: CatalogJanitor warns about skipping gc of regions during RIT, but does not actually skip
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 03/May/21 19:08
Affects Version/s: 2.4.3

Found while looking for something else. 

We claim in a WARN level log line to {{"Playing-it-safe skipping merge/split gc'ing of regions from hbase:meta while regions-in-transition (RIT)"}} but do not actually skip because of a missing return. 

Playing it safe has proven unnecessary, I would say. Nonetheless here is a patch that adds the missing return, for discussion.
Bug: IntegrationTestLoadCommonCrawl
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 28/Apr/21 23:26

This integration test loads successful resource retrieval records from the Common Crawl (https://commoncrawl.org/) public dataset into an HBase table and writes records that can be used to later verify the presence and integrity of those records.

Run like:
{noformat}
./bin/hbase org.apache.hadoop.hbase.test.IntegrationTestLoadCommonCrawl \
  -files /path/to/hadoop-aws.jar \
  -Dfs.s3n.awsAccessKeyId=<AWS access key> \
  -Dfs.s3n.awsSecretAccessKey=<AWS secret key> \
  /path/to/test-CC-MAIN-2021-10-warc.paths.gz \
  /path/to/tmp/warc-loader-output
 {noformat}

Access to the Common Crawl dataset in S3 is made available to anyone by Amazon AWS, but Hadoop's S3N filesystem still requires valid access credentials to initialize.

The input path can either specify a directory or a file. The file may optionally be compressed with gzip. If a directory, the loader expects the directory to contain one or more WARC files from the Common Crawl dataset. If a file, the loader expects a list of Hadoop S3N URIs which point to S3 locations for one or more WARC files from the Common Crawl dataset, one URI per line. Lines should be terminated with the UNIX line terminator.

Included in hbase-it/src/test/resources/CC-MAIN-2021-10-warc.paths.gz is a list of all WARC files comprising the Q1 2021 crawl archive. There are 64,000 WARC files in this data set, each containing ~1GB of gzipped data. The WARC files contain several record types, such as metadata, request, and response, but we only load the response record types. If the HBase table schema does not specify compression (by default) there is roughly a 10x expansion. Loading the complete CC-MAIN-2021-10 crawl archive results in a table approximately 640 TB in size.

The hadoop-aws jar will be needed at runtime to instantiate the S3N filesystem. Use the -files ToolRunner argument to add it.

You can also split the Loader and Verify stages:

Load with:

{noformat}
./bin/hbase 'org.apache.hadoop.hbase.test.IntegrationTestLoadCommonCrawl$Loader' \
  -files /path/to/hadoop-aws.jar \
  -Dfs.s3n.awsAccessKeyId=<AWS access key> \
  -Dfs.s3n.awsSecretAccessKey=<AWS secret key> \
  /path/to/test-CC-MAIN-2021-10-warc.paths.gz \
  /path/to/tmp/warc-loader-output
{noformat}

Verify with:

{noformat}
./bin/hbase 'org.apache.hadoop.hbase.test.IntegrationTestLoadCommonCrawl$Verify' \
  /path/to/tmp/warc-loader-output
{noformat}
Bug: HBase Configuration File Descriptions has some description errors or inaccurate
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 02/May/21 09:24
Affects Version/s: 3.0.0-alpha-1

In Apache HBase ™ Reference Guide

*Need to modify part1：*
 _3 Configuration Files->HBase Configuration File Descriptions->log4j.properties_

*explanation：*
 HBase 3.0.0 log frame is now log4j2，so need to update dectiption like follows:

log4j2.xml
 Configuration file for HBase logging via log4j2.

*Need to modify part2：*
 _3 Configuration Files->HBase Configuration File Descriptions->hbase-site.xml_
 You can view (but do not edit) the default configuration file at docs/hbase-default.xml.

*explanation：*
 maybe we need to update hbase-default.xml filePath to hbase-common/src/main/resources/hbase-default.xml